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WELCOME 


The  Institute  for  Computer  Sciences  and  Technology  and  the  National 

(  imputer  Security  Center  are  pleased  to  welcome  you  to  this  Annual 

/ 

Computer  Security  Conference.  The  past  eight  conferences  have  stimulated 
the  sharing  cf  information  and  the  application  of  new  technology. 

This  year's  conference  theme  —  Computer  Security  -  Today  ...  and 
Tomorrow  --  reflects  the  growth  of  computer  security  awareness  and  a 
maturation  of  the  technology  and  its  use.  The  efforts  of  the  National 
Bureau  of  Standards,  the  National  Computer  Security  Center,  computer 
users,  and  industry  have  helped  to  bring  about  the  progress  that  has  been 
made  in  the  past  few  years.  The  commitment  of  the  Federal  government  and 
private  industry  to  improve  computer  security  continues  to  grow,  and 
trusted  systems  and  other  technologies  are  becoming  available. 

But  much  more  needs  to  be  done.  Federal  government  executive  and 
legislative  initiatives  for  computer  security  show  the  extent  of  national 
concern.  We  must  strengthen  our  efforts  to  make  managers,  executives, 
and  computer  users  strong  advocates  for  computer  security,  and  we  must 
make  full  use  of  the  best  affordable  technology. 


Your  participation  in  this  meeting  can  help  to  achieve  this  goal. 
Let's  continue  to  exchange  ideas  and  then  go  back  to  our  organizations 
with  renewed  purpose  and  commitment  to  improve  the  security  of  our  systems 
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MES  H.  BURROWS 
Di rector 

Institute  for  Computer  Sciences 
and  Technology 


PATRICK  R.  GALLAGHER,  JR.  L 
Di rector 

National  Computer  Security 
Center 
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A  Brief  Summary  of  a 
Verification  Assessment  Study 

Richard  A.  Kemmerer 

ucpar t.ment  of  Computer  Science 
university  of  California 
Santa  Barbara,  California  93106 


Introduction 


This  paper  is  a  brief  summary  of  a 
verification  assessment  study  that  was 
begun  in  November  1984  and  lasted  for 
approximately  nine  months.  The  final 
report  (Kern  86) ,  which  consists  of  five 
volumes,  can  be  obtained  from  tne 
National  Computer  Security  Center. 

The  main  goal  of  this  effort  was  a 
technology  interchange  among  the  developers 
of  four  established  verification  systems. 
The  systems  investigated  were  i)  Affirm 
(General  Electric  Company,  Schenectady, 

New  York) ,  ii)  FDM  (System  Development 
Corporation  -  A  Burroughs  Company, 

Santa  Monica,  California) ,  iii)  Gypsy 
(the  University  of  Texas  at  Austin,  Austin, 
Texas) ,  and  iv)  Enhanced  HUM  (SRI 
International,  Menlo  Park,  California). 
There  was  some  comparative  work  on  examples 
but  the  main  idea  was  for  the  developers 
to  learn  the  details  of  each  other's  system 
as  a  basis  for  future  development. 

It  was  not  the  goal  of  this  study  to 
rate  the  verification  systems  that  were 
investigated.  It  was  also  not  the  intent 
of  the  study  to  justify  the  need  for 
formal  specification  and  verification 
systems  or  to  justify  the  necessity  for 
research  in  this  area. 

The  next  section  gives  an  overview  of 
the  study.  This  is  followed  by  a  summary 
of  some  of  the  issues  raised  by  and 
conclusions  drawn  fcom  the  study. 

Overview  of  the  Verification  Assessment 
Study 

The  approach  taken  for  this  study  was 
first  to  select  a  suitable  set  of  example 
problems  to  be  used  to  investigate  the 
established  systems.  Each  of  the  systems 
in  turn  was  used  to  specify  and  verify 
these  problems.  The  specification  and 
verification  was  performed  by  the 
development  team  for  each  system.  One 
member  of  each  system's  development  team 
was  picked  as  the  "representative"  for  that 
particular  system.  The  system 
representatives  were  well  established  with 
regard  to  their  in-depth  knowledge  of  th  t 
particular  verification  system.  In  most 
cases  the  representative  was  one  of  the 
original  developers  of  the  system.  The 
AFFIRM  representative  was  Dave  Musser, 
currently  with  the  Computer  Science  Branch 
at  the  General  Electric  Company’s  Corporate 
Research  and  Development  Center  in 
Schenectady^  New  York  The  FDM 
representative  was  Deborah  Cooper  from 


System  Development  Corporation's 
Santa  Monica  Research  Center  in 
Santa  Monica,  California.  The  Gypsy 
representative  was  Don  Good  from  the 
Institute  for  Computing  Science  at  the 
University  of  Texas  at  Austin  in  Austin, 
Texas.  The  HDM  representative  was 
Karl  Levitt  from  SRI  International's 
Computer  Science  Laboratory  in  Menlo  Park, 
California.  In  addition  to  the  system 
representatives,  the  assessment  team,  also 
included  two  independent  participants: 

Dan  Craigen  from  l.P.  Sharp  Associates  in 
Ottawa,  Canada,  and  Dick  Keinmerer. 

Tad  Taylor,  the  sponsor's  technical 
liaison,  also  participated  in  the  process. 

At  the  initial,  meeting  the  group 
agreed  on  the  set  of  example  problems  that 
would  be  specified  and  verified  using  each 
of  the  systems.  The  p^int  of  these 
examples  was  to  determine  how  the  system 
developers  would  proceed  in  solving  the 
problem.  It  was  noped  that  ideas  as  to 
how  these  problems  should  be  solved,  using 
the  various  methodologies,  would  arise. 

In  addition,  it  was  expected  that  the 
strengths  and  weaknesses  of  the  systems 
and  supporting  languages  and  methodologies 
would  also  be  uncovered.  Finally,  it  was 
the  hope  of  the  sponsoring  agent  that 
these  examples  would  provide  insight  into 
how  a  common  set  of  problems  might  be  used 
for  comparing  veritication  systems. 

For  each  of  the  four  systems,  the 
specification  and  verification  of  the 
example  problems  was  done  by  the 
development  team  for  that  particular 
system.  The  nonresident  members  or  the 
assessment  group  then  visited  the  home 
site  of  each  system  to  study  the  system 
and  the  solutions  to  the 
problems. 

During  the  site  visits,  each 
participant  was  allowed  to  study  the 
system  in  any  way  he  or  she  wished. 
Usually,  this  meant  that  the  participant 
defined  a  favorite  problem  and 
investigated  the  effects  that  the  system 
had  on  the  development  of  a  solution. 

For  example,  Don  Good  and  Dan  Craigen 
teamed  up,  for  the  last  three  visits, 
and  worked  with  a  micro-modulator  example, 
and  Dick  Kemmerer  worked  with  a  secure 
terminal  example  on  each  of  the  four 
systems. 

Moreover,  the  participants 
concentrated  their  efforts  on  areas  in 
which  they  were  particularly  interested 
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and  U ied  to  understand  those  parts 
thoroughly.  Dave  Musser,  for  example 
direct’d  his  attention  to  the  theorem 
proving  aspects  of  the  systems. 

Dan  Craigei.  was  interested  in  language 
and  metnodological  concerns,  and 
Dick  Kemmerer  was  interested  in 
specify ing  a  large  and  'real."  example. 

Through  tiiis  technical  interchange 
members  of  both  the  assessment  group  and 
development  teams  presented  their  system 
while  the  nonresident  participants 
observed  the  approaches  used  to  speci  y 
and  verify  the  example  problems. 

After  visiting  a  ^ite,  each  of  the 
nonresident  participants  prepared  a 
critique  of  tha  particular  system.  After 
all  the  site  ^ isits  had  been  completed, 
the  assessment  team  convened  at  the 
University  of  California  in  Santa  Barbara, 
to  compare  their  findings,  to  discuss  the 
relevant  verification  technology  issues 
that  were  raised  during  the  study,  and  to 
propose  future  directions  for  verification 
research. 

Technology  Interchange 

The  technology  interchange  that  was 
the  primary  goal  of  tnis  study  did  occur. 
One  type  of  technology  transfer  that 
occurred  was  the  result  of  tne  nonresident 
participants  exercising  the  systems  and 
discovering  bugs  and  weaknesses  for  the 
developers.  The  value  of  this  type  of 
information  is  documented  in  the 
individual  critiques  and  the  responses  to 
the  critiques  (contained  in  Volumes  II-V 
of  the  final  report  for  this  study 
(Kem  86) ) . 

Anothe  type  of  interchange  was  from 
system  to  system.  Several  of  the 
developers  mentioned  during  the  later 
visits  that  they  had  incorporated  (or 
planned  to  incorporate)  changes  to  tneir 
systems  based  on  what  they  had  learned 
from  the  site  visits.  This  was 
particularly  evident  during  the  SRI  visit 
because  it  was  the  last  visit  and  because 
tile  Enhanced  FDM  system  is  in  an  early 
stage  of  development . 

The  strengths  and  the  weaknesses  of 
the  four  systems  that  were  observed  also 
served  as  a  basis  for  formulating  the 
components  of  a  state-of-the-art 
verification  system  and  for  identifying 
areas  that  need  further  research.  For 
example,  the  move  toward  a  more  friendly 
user  interface  that  was  apparent  in  all 
of  the  systems  clearly  demonstrated  the 
desirability  of  such  interfaces.  It  also 
revealed  the  need  to  continue  to  move  in 
this  direction  incorporating  the  power 
of  bit  mapped  graphic  displays  and 
windowing  capabilities  into  the 
verification  systems. 


Example  Problems 

One  of  the  conclusions  drawn  from  this 
study  is  that  the  example  problems  were 
not  "benchmarks".  That  is,  they  could  not 
be  used  to  measure  the  "quality"  of  a 
verification  system.  This  result  is  not 
surprising,  particularly  since  all  of  the 
specification  languages  are  based  on 
first-order  predicate  calculus,  and  one 
can,  therefore,  specify  the  same  kinds  of 
properties  in  all  c£  them. 

It  is  also  a  well  known  fact  that  any 
testing  other  than  exhaustive,  testing  is 
not  complete.  The  examnle  problems  were 
five  test  cases  that  were  tried  on  each  of 
the  verification  systems.  This  is  not 
exhaustive  testing. 

On  the  positive  side  it  should  be 
noted  that  the  five  examples  did  provide 
some  common  ground  for  comparing  and 
contrasting  the  four  systems.  The 
individual  critiques  discuss  some  of  the 
strengths  and  weaknesses  of  the  systems 
and  languages  that  were  revealed  when 
reviewing  the  solutions  to  the  example 
problems . 

Formal  Verification  for  Secure  Systems 

The  security  community  has  been  a 
major  source  of  funding  for  the 
application  of  formal  technologies  and  the 
development  of  formal  verification  systems 
for  the  last  ten  years.  Their  interest  is 
in  tne  use  of  formal  verification  to 
increase  their  confidence  in  the  security 
of  the  systems  they  are  building. 

Ever  since  the  Anderson  Study  defined 
the  reference  monitor  in  1972  (And  72), 
security  kernels  tiave  been  an  integral 
part  of  most  secure  systems,  it  is  the 
desire  to  achieve  the  third  requirement 
of  a  reference  monitor  (it  must  be  small 
enough  to  be  subjected  to  analysis  and 
test)  that  has  motivated  the  security 
community  to  embrace  formal  verification 
technologies.  That  is,  one  form  of 
analysis  is  formal  verification.  If  one 
looks  up  the  definition  of  a  security 
kernel  in  the  Dod  Trusted  Computer  System 
Evaluation  Criteria  (commonly  referred  to 
as  the  "Orange  Book")  (DoD  83)  the  third 
requirement  has  been  replaced  by  be 
verifiable  as  correct".  Furthermore,  the 
difference  between  the  highest  level  of 
trust  (Al)  and  the  next  lower  level  (B3) 
is  “the  analysis  derived  from  formal 
design  specification  and  verification 
techniques  and  the  resulting  high  degree 
of  assurance  that  the  TCB  (Trusted 
Computing  Base)  is  correctly  implemented," 

The  reason  that  the  security  community 
turned  to  formal  verification  for  this 
added  assurance  is  that  testing  techniques 
are  not  sufficient  for  giving  the  desired 
confidence  in  the  systems  being  built, 


One  must  keep  in  mind,  however,  that 
that  secure  systems  are  just  one  class  of 
reliable  systems  (those  whose  reliability 
is  defined  in  terms  of  security 
requirements) .  Therefore,  the  benefits 
of  formal  verification  are  the  same  as 
for  any  reliable  software  development 
project.  The  use  of  formal  verification 
techniques  helps  to  avoid  sloppy  thinking 
and  the  verification  systems  keep  one 
"honest".  That  is,  by  using  formal 
specifications  one  can  precisely  document 
the  requirements  of  a  system  in 
unambiguous  terms.  Furthermore,  because 
the  specifications  are  written  in  a 
formal  notation,  one  can  reason  about  the 
specifications  and  one  can  also  analyze 
them  using  computerized  tools.  Thus, 
properties  can  be  proved  about  the 
specifications. 

In  summary,  the  security  community's 
motivation  for  using  formal  verfication 
techniques  is  no  different  than  those  of 
anyone  wanting  reliable  software.  There 
is  a  difference,  however,  in  the 
properties  proved. 

Formal  Semantics  and  Mathematical 
Justification 

One  of  the  issues  that  was  raised 
during  the  study  was  the  need  for  formal 
sematics  for  the  specification  and 
programming  languages  and  a  mathematical 
justification  for  the  proof  approach 
being  used.  There  was  a  consensus  within 
the  group  that  formal  semantics  and  a 
mathematical  justification  would  be  good 
to  have.  However,  there  was  a  difference 
of  opinion  about  the  role  of  these 
mathematical  foundations  in  verification 
system  development.  The  question  raised 
by  the  assessment  group  was  "is  it 
necessary  to  have  the  formal  semantics 
and  the  mathematical  justification  all 
rigorously  defined  before  building  a 
system  or  is  it.  better  to  begin  building 
a  system,  while  having  only  a  partial 
formulation  of  its  foundations?"  This 
issue  was  not  resolved  during  the  study. 
Horne  participants  felt  that  it.  is 
necessary  to  have  the  formal  semantics 
play  an  active  role  during  the  design  of 
the  specification  languages,  programming 
languages,  and  the  underlying  logic. 
Therefore,  the  formal  semantics  should  be 
fully  defined  before  going  off  to  build  a 
verification  system.  Other  team  members 
felt  that  if  one  insisted  on  formal 
semantics  before  anything  else,  the 
verification  system  might  never  get  built, 
and  that  one  can  have  useful  systems 
without  fully  defining  the  formal 
semantics.  The  four  verification 
systems  that  were  investigated  in  thi s 
study  were  built  without  the  formal 
semantics  being  fully  defined  (if 
defined  at  all).  However,  Don  Good 
remarked  that  he  thought  that  not 
having  developed  a  formal  semantics  for 
Gypsy  as  a  part  of  the  language 
development  was  one  of  the  most  serious 
mistakes  made  in  the  Gypsy  effort. 


Design  Verification 

Another  issue  that  was  raised  during 
the  study  is  "what  is  design  verification 
and  or  what  use  is  it."  The  DoD  Trusted 
Computer  System  Evaluation  Criteria 
requires  design  verification  for  systems 
rated  at  the  highest  level  of  confidence 
(Division  A  systems) .  The  orange  book 
(DoD  83)  defines  design  verification  as 

"the  process  of  using  formal  proofs 

to  demonstrate  the  consistency 

between  a  formal  specification  and  a 

formal  security  policy". 

An  identical  definition  is  given  in  the 
COMPUSECese  Computer  Security  Glossary 
(DoD  85) . 

After  much  discussion  the  issue  was 
reduced  to  whether  "design"  verification 
is  the  appropriate  term.  What  is  being 
verified  is  a  specification  and  not  a 
design,  although  the  specification  may  be 
part  of  the  design  process.  The  group  was 
also  concerned  that  the  term  "design" 
carries  a  connotation  of  being  complete 
while  a  specification  is  often  incomplete. 

To  help  settle  the  question  the 
available  software  engineering  texts 
(approximatly  ten  of  them)  were  consulted 
to  determine  the  appropriate  definition  of 
"design".  The  hypothesis  was  that  design 
was  a  well  understood  term  in  the  software 
engineering  community.  The  surprising 
result  of  this  search  was  that  most  of  the 
definitions  of  design  were  ambiguous,  and 
of  those  that  were  not  ambiguous,  there 
was  little  agreement  as  to  what 
constitutes  a  design.  Because  the 
investigation  revealed  that  the  term 
design  was  not  as  well  understood  as  was 
originally  thought,  the  group  decided  to 
take  a  fresh  look  at  the  process  that  was 
being  defined  to  determine  if  there  was  a 
more  accurate  term  for  the  process 

The  consensus  was  that  a  specification 
was  a  description  of  some  property ( ies)  of 
a  system.  Furthermore,  security  models 
are  high  level  specifications.  The  group 
also  agreed  that  it  was  useful  to  prove 
properties  about  specifications,  and  that 
testing  and  proving  properties  about 
specifications  (possibly  even  incomplete 
specifications)  is  pne  way  of  gaining 
confidence  that  the  specifications  satisfy 
some  desired  properties. 

The  conclusion  was  that  what  was 
taking  place  were  proofs  about 
specifications.  Therefore,  the  term 
"specification  verification"  more 
accurately  describes  the  process  commonly 
referred  to  as  "design  verification". 

Is  Formal  Verification  a  Stagnant  Field? 

It  has  been  suggested,  especially 
during  the  last  verification  workshop, 
that  the  field  of  formal  verification  is 
in  a  state  of  stagnancy.  The  particular 
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observation  made  at  VERkshop  III  (Ver  85) 
was  that  very  little  seems  to  have  been 
accomplished  since  the  previous  workshop 
(neld  four  years  earlier) . 

Computing  science  in  general,  and 
formal  verification  in  particular,  are 
addressing  some  v?ry  real  and  difficu-.t 
problems.  Formal  verification  is  a 
multidisciplinary  field.  It  requires 
understanding  of  programming  and 
specification  languages,  programming  and 
specification  methodologies,  mathematics 
(both  for  reasoning  about  programs  and 
and  systems  and  for  describing  languages), 
and  system  interfaces.  To  engineer  these 
technologies  into  a  cohesive  whole  is 
extremely  difficult,  but  the  payoffs  could 
be  substantial.  If  the  development  of 
verification  systems  has  been  slow,  it  is 
because  of  these  fundamental  challenges. 

A  Production  Quality  Verification 
System 

The  four  verification  systems  examined 
in  this  study  represent  the  leading  edge 
of  mechanical  verification  technology. 

This  mechanical  support  is  useful,  if  not 
necessary,  when  applying  formal 
verification  to  real  applications. 

However,  each  of  these  systems  has  been 
built  primarily  as  a  research  vehicle  for 
exploring  different  ways  of  implementing 
and  applying  formal  verification.  None 
of  them  has  been  designed  or  implemented 
as  the  kind  of  production  quality  system 
that  is  needed  to  support  wide-spread 
application  of  verification  to  real 
software  systems.  There  is  much  that 
needs  to  be  done  to  progress  from  where 
the  systems  are  now  to  a  truly  production 
quality  verification  system. 

The  most  important  requirement  for  a 
production  quality  verification  system  is 
soundness.  Soundness  for  a  verification 
system  means  thao  if  the  verification 
system  claims  tiiat  an  application  is 
proved  and  the  assumptions  underlying  the 
verification  system  are  true  (correct 
hardware,  compiler,  etc),  then  the 
application  actually  will  exhibit  the 
properties  that  the  verification  system 
claims  to  have  proved  about  it.  Without 
soundness,  the  results  of  a  verification 
(be  it  mechanical  or  otherwise)  cannot 
be  trusted.  If  a  verification  system 
is  to  be  used  in  any  important  application, 
soundness  must  be  given  top  priority. 


Each  of  the  research  prototypes  that, 
were  studied  has  some  areas  of 
unsoundness.  Often  the  cause  of  this 
unsoundness  simply  is  that  the 
implementations  of  the  existing  systems 
are  incomplete  in  some  important  way. 

These  problem  areas  usually  can  be  avoided 
or  finessed  by  an  expert  user;  but  this 
level  of  expertise  cannot  be  assumed  for 
the  potential  user  community  of  a 
production  system.  As  mentioned  above, 
one  way  in  which  all  of  the  four  systems 
are  incomplete  is  that  none  of  them  have  a 
fully  developed,  mathematically  precise 
definition  of  the  semantics  of  the 
languages  they  process.  This  is  the 
standard  against  which  a  rigorous 
determination  of  the  soundness  must  be 
made . 

A  production  quality  verification 
system  must  be  well  engineered.  It  needs 
to  have  a  high  quality  user  interface.  It 
must  perform  efficiently.  It  must  be 
robust,  well  documented,  maintainable, 
etc.  It  should  be  built  with  the  best 
methods  available  for  software 
engineering,  quality  control, 
configuration  management,  etc.  Generally, 
these  issues  have  not  been  given  a  high 
priority  in  the  implementation  of  the 
research  prototypes,  and  all  of  them  have 
major  deficiencies  in  some  of  these  areas. 
The  current  systems  have  been  developed 
primarily  to  demonstrate  the  feasibility 
of  i)  mechanizing  formal  verification 
and  ii)  applying  it  to  real  software 
systems.  They  have  served  that  purpose 
well,  but  they  are  far  from  being 
production  quality  systems. 

A  production  quality  system  that  is 
to  be  used  by  a  large  community  must  be 
hosted  on  equipment  that  is  readily 
available  to  that  community.  The 
National  Computer  Security  Center  has 
taken  a  first  step  in  this  direction  by 
making  the  FDM,  Gypsy,  and  HDM  (both 
the  original  and  the  enhanced) 
verification  systems  and  the 
Boyer-Moore  theorem  prover  available 
a  Multics  system  on  the  ARPAnet,  This 
is  a  reasonable  first  step;  however, 
due  to  the  limited  Multics  user 
community  (as  compared  to  TOPS20,  or 
UNIX)  and  the  dissatisfaction  of 
having  to  work  over  the  ARPAnet,  some 
or her  means  of  reaching  a  wider  audience 
must  be  found. 


If  a  production  quality  system  is  to 
be  made  available  on  a  wide-spread  basis, 
education  of  the  potential  user  community 
will  also  be  required.  This  community 
will  need  to  be  educated  in  the 
fundamentals  of  verification  as  well  in 
the  use  of  mechanical  verification  tools. 
The  existing  research  prototype  systems 
can  play  a  useful  role  cere.  They  can  be 
used  to  help  educate  the  community,  and 
they  can  be  used  to  explore  a  wider 
variety  of  applications  of  formal 
verification.  Demonstrating  the 
effectiveness  of  verification  on  an 
increasing  variety  of  important 
applications  probably  is  the  best  way 
of  drawing  the  attention  of  the 
software  engineering  community  to 
verification,  and  thereby  accelerating 
its  development. 

Verifiability  of  Ada 

Currently,  there  is  a  significant 
degree  of  interest  in  determining 
whether  the  programming  language  of  Ada 
is  amenable  to  formal  program 
verification  techniques.  This  incerest 
is  particularly  evident  in  the  security 
community.  This  interest  in  Ada 
Verification  is  most  likely  the  result 
of  the  following  line  of  reasoning. 

DoD  Directive  5000.31  states  that  Ada  is 
to  be  used  for  all  mission  critical 
embedded  systems  software.  It  is 
reasonable  to  assume  that  secure 
systems  are  mission  critical. 

Furthermore,  secure  systems  that  are  to 
be  certified  at  the  A1  level  require 
formal  verification.  Therefore,  if  is 
reasonable  to  assume  that  Ada 
verification  may  be  required  for  secure 
systems . 

This  line  of  reasoning  may  seem 
plausible;  however,  it  should  be  noted 
that  no  DoD  requirement  for  code 
verification  exists.  At  the  A.l  level 
the  requirement  is  for  a  manual  c.r 
other  mapping  between  the  formal 
specification  and  the  source  code,  to 
provide  evidence  of  correct 
implementation. 

While  it  was  the  collective  opinion 
of  the  assessment  group  that  a  verifiable 
subset  of  Ada  can  be  found,  the  group 
also  believed  that  it  was  necessary  tc 
note  some  important  observations  and 
concerns. 

The  main  problem  noted  is  that  Ada  is 
a  particularly  complex  language.  As  a 
result,  finding  a  useful  and  easily 
determinable  axiomatizable  subset  of  Ada 
is  a  difficult  task.  The  group  concluded 
that  before  building  an  Ada  verification 
system  time  should  be  spent  trying  to 
understand  the  components  of  Ada  that 
contribute  to  its  complexity. 


Research  Directions 

It  was  concluded  that  what  is  needed 
to  make  a  significant  advance  in  the  use 
of  formal  verification  for  reliable 
software  is  a  variety  of  "exploratory 
applications”  that  explore  the  potential 
utility  of  verification  technology.  This 
experimentation  shuld  result  in  a  variety 
of  publicly  visible  examples  that  show  the 
benefits  of  formal  verification.  It  would 
also  be  desirable  to  have  a  technology 
that  gets  accepted  without  being  mandated 
by  the  National  Computer  Security  Center 
or  the  government  in  general.  That  is, 
one  would  like  the  general  public  to  view 
the  examples  and  conclude  that  this  is  how 
they  would  like  to  build  their  systems. 

To  achieve  success  would  require 
experimentation  on  a  wide  variety  of 
examples.  It  would  be  beneficial  to  have 
the  academic,  industrial,  and  government 
communities  all  involved  in  this 
experimentation.  To  carry  out  the 
examples  would  require  a  long  term 
commitment  from  funding  agencies. 

One  of  the  side  effects  of  these 
experiments  is  that  the  limits  of  the 
verification  techniques  would  be  made 
known  and  the  areas  in  need  of  further 
research  would  be  exposed.  Another 
benefit  of  the  experiments  would  be 
production  quality  systems,  for  without 
them  there  would  be  no  hope  of  public 
acceptance. 

Conclusions 

It  should  be  noted  that  the 
conclusions  contained  in  this  paper  are 
the  result  of  looking  at  four  verification 
systems.  Although  the  assessment  team 
members  brought  a  large  amount  of  formal 
verification  knowledge  to  the  study,  the 
reader  should  be  aware  that  this  is  a 
view  oi  the  total  field  of  formal 
verification.  It  was  evident  from  this 
study  that  although  it  is  possible  to  gain 
valuable  insight  and  understanding  during 
a  one  week  visit,  it  in  impossible  to 
fully  understand  a  system  in  such  a  short 
time. 

Acknowledgements 

I  would  like  to  thank  the  members  of 
the  assessment  team  for  their  dedication 
to  this  study.  They  approached  the  study 
with  open  minds  that  provided  a  refreshing 
academic  atmosphere  for  exchanging  ideas 
and  knowledge. 

I  would  also  like  to  thank  the 
associations  that  hosted  each  of  the  site 
visits  for  giving  so  generously  of  their 
time  and  facilities.  Particular  thanks 
goes  to  the  development  'cam':  for  each  of 
the  systems  who  made  each  of  the  site 
visits  an  enjoyable  learning  experience. 


References 


(And  72)  Anderson,  J.P,,  Computer  Security 
Technology  Planning  Study , 
ESD-TR-73-51,  Vol.  I,  AD-758  206, 
ESD/AFSC,  Hanscom  AFB,  Bedford, 
Massachusetts,  October  1972 

(DoD  83)  Department  of  Defense  Trusted 
Computer  System  Evaluation 
Criteria,  CSC-STD-001-83 , 
Department  of  Defense  Computer 
Security  Center,  Fort  George 
Meade,  Maryland,  August  1983 

(DoD  85)  CQMPUSECese  Computer  Security 
Glossary,  NCSC-WA-C01-85 , 

National  Computer  Security 
Center,  Fort  George  Meade, 
Maryland,  October  1985 


(Ke.m  86)  Kemmerer,  R.A. ,  Verification 
Assessment  Study  Final  Report, 
Volumes  I  -  V,  C3-CR01-86, 

National  Computer  Security 
Center,  Fort  George  Meade, 
Maryland,  January  1986 

(Ver  85)  Proceedings  of  VERkshop  III  — 

A  Formal  Verification  Workshop, 
Pajaro  Dunes  Conference  Center, 
Watsonville,  California, 

February  1985,  Sof tware 
Engineering  Notes,  Vol.  10,  No,  4, 
August  1985 


6 


A  NETWORK  SECURITY  PERSPECTIVE 


Jonathan  K.  Nlillen 
The  MITRE  Corporation 
Bedford.  MA  01730 


l.  INTRODUCTION 

BACKGROUND 

Network  secur'd  /  is  roughly  at  the  same  stage  ADR 
system  security  was  al  nut-  ten  years  ago,  when  prototypes  or 
the  first  multilevel  see  ire  systems  '.ere  being  built.  Systems 
with  some  degree  of  security  already  existed,  but  il-  was 
important  to  have  svs  ems  that  were  more  flexible  (including 
the  ability  to  support  DoD  needs),  and  which  provided  an 
assurar.  :e  of  security  t  used  on  more  than  a  limited  amount  of 
testing  and  a  firm  ham  shake. 

■Secure  networks  in  some  sense,  are  all  around  us.  "f  he 
ARPANET  lias  been  used  to  carry  classified  information, 
using  PLl’s  (BBN’s  Pri  ’ate  Line  Interface)  to  provide  end-to- 
end  e  tcrypLion.  Circuit-switched  networks  employ  link 
encryption  devices  to  si  t  up  secure  channels.  Banks  use  DES- 
based  encryption  to  p  'otect  funds  transfers.  But  modern 
packet-switching  networks  present  many  oppoitunilies  and 
problems  that  have  not  .’et  been  fully  explored. 

The  phased  devi  lopment  and  growth  of  DDN  as  a 
backbone  network  to  r  irry  classified  i.iformation,  and  the 
development  of  distributed  application-level  networks  such  as 
■SACDIN  and  DoDIlS  tint  will  make  use  of  its  services,  make 
it  necessary  to  unde  ret  a  id  and  plan  for  the  more  advanced 
capabilities  envisioned  fo-  the  future,  its  well  as  the  concerns 
arising  from  the  interconnection  of  a  wide  variety  of  ADP 
systems  in  a  common  internet  environment. 

Many  important  network  security  issues  weie  brought 
out  i  i  a  Spring,  TnSo  DoD  Workshop  organized  by  the 
Naticnal  Computer  Security  Center  (NCSC)  (l).  The 
objective  of  the  Workshop  was  to  provide  the  NCSC  with 
input  for  the  development  of  trusted  network  evaluation 
criteria,  analogous  to  the  Trusted  Computer  System 
Evaluation  Criteria  (TCSEC)  |2|.  The  network  criteria  would 
provide  technical  guidance  for  the  DoD  in  the  evaluation  and 
acquisition  of  network:;  in  which  security  needs  are 
significant.  It  was  clear  that  much  of  the  organization  and 
content  of  the  TCSEC  applied  io  network  evaluation,  but 
also  that  the  TCSEC  was  deficient  or  inapplicable  in  some 
resptets  for  this  purpose.  The  TCSEC  needed  to  he  revised, 
replaced,  extended,  nr  at  least  reinterpreted  for  network 
evaluation. 

A  number  of  issues  discussed  in  the  Workshop  are  still 
unresolved  Some  of  the  unresolved  issues  are  very  basic, 
such  as  whether  tile  run  cut  slate  of  the  art  is  adequate  to 
certify  any  networks  .is  secure  at  an  “A"  level,  implying  a 
high  assurance  of  security  comparable  to  A-level  standalone 


systems.  Another  basic  concern  is  the  scope  of  the  criteria; 
what  exactly  is  a  network,  and  what  kinds  of  networks  can 
f°3sonably  be  evaluated? 

ISSUES  OVERVIEW 

The  need  for  ee.tain  significant  additions  and  changes 
in  the  TCSEC  to  adapt-  it  for  network  evaluation  emerged 
from  -lie  Workshop.  Some  of  the  more  notable 
characteristics  of  network  evaluation  that  distinguish  it  from 
the  standalone  system  evalution  are  summarized  below. 
While  each  of  these  "haracteristics  is  a  response  to  issues  that 
demanded  attention,  there  are,  in  some  cases,  disagreements 
about  how  to  deal  with  them;  those  disagreements  arc 
indwaied  below  as  well. 

The  chat  acteristics  touched  upon  in  this  subsection 
are:  the  global  vs.  component  view  of  a  network,  trusted 
paths,  interconnection  rules,  communications  integrity  and 
denial  of  service,  treatment  of  non-host  components,  and 
encryption.  The  following  subsection  begins  the  main  topic 
of  this  report,  the  relation  between  security  policy  and 
protocol  layering,  and  how  it  should  affect  network 
evaluation. 

One  pervasive  theme  of  the  Workshop  was  the  need  to 
view  a  network  both  as  a  global  entity  with  a  single  security 
policy,  and  as  a  collection  of  components  that  must  be 
individually  specified  and  evaluated.  For  secure  operation,  a 
network  is  bound  to  have  certain  standai  ds,  restrictions,  and 
conventions  that  must  be  obeyed  and  enforced  network-wide 
to  obtain  assurances  that  all  users  can  count  un.  In 
particular,  same  networks  will  have  centralized  facilities  like 
access  control  centers  and  repositories  of  audit  information 
whose  proper  use  must  be  specified  and  enforced  globally. 

At  the  same  time,  networks  are  normally  developed  by 
connecting  together  a  variety  of  different  components  with 
different  functions,  many  of  which  existed  independently  prior 
to  the  network  or  were  off-the-shelf  commercial  products.  Il 
is  important  to  foster  the  development  of  future  products  of 
this  sort  by  understanding  how  to  evaluate  their  designs  on 
their  own,  to  the  cxlert  possible,  out  of  the  context  of  any 
specific  network. 

The  trusted  path  requirement  is  an  extension  of  an 
authentication  requirement  found  in  secure  operating  systems. 
In  a  standalone  system,  there  are  times  when  a  human  user 
must  communicate  directly  with  trusted  software,  without 
any  possibility  of  undetected  interference  or  forgery  by 
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unlrustcd  software.  This  occurs,  for  example,  when  a  user  is 
presenting  a  password  for  login,  since  it  should  he  read  only 
by  trusted  software;  and  when  a  privileged  operation  is  being 
requested,  since  the  request  should  be  honored  only  from  an 
authorized  person,  in  a  network,  there  are  times  when 
trusted  processes  in  different  sites  must  share  a  similarly 
protected  channel.  For  example,  one  host  may  relay  a  local 
user's  password  to  a  remote  host,  or  send  security-related 
reconfiguration  instructions  from  a  local  network 
administrator  to  a  remote  site. 

The  interconnection  rules  are  a  statement  of 
mandatory  access  control  policy  at  a  level  of  abstraction  (or  a 
layer  of  protocol)  for  which  the  network  provides  data  links 
between  potentially  multilevel  components.  These  rules  are 
an  explicit  assurance  to  host  administrators  that  their  data 
will  not  be  sent  to  other  hosts  that  are  not  accredited  to 
receive  it.  The  current  rules  assume  that  data  links  are 
bidirectional,  because  of  the  usual  need  for  acknowledgements 
and  other  two-way  coordination  when  setting  up  connections. 
In  some  applications  there  is  a  need  for  true  one-way  data 
flow,  and  there  is  a  question  whether  one-way  data  links 
should  be  recognized  by  the  interconnection  rules,  or  whether 
they  should  be  treated  as  something  that  occurs  invisibly 
inside  a  trusted  component. 

Tiie  requirements  relating  to  communications  integrity 
and  denial  of  service  result  from  the  general  feeling  that  these 
concerns,  while  already  present  for  standalone  computer 
systems,  arc  more  serious  in  a  network  context,  because  of 
the  greater  vulnerability  of  communications  links  to  random 
errors,  wiretapping,  and  other  threats  affecting  data  in 
transit.  Hence,  thougli  they  are  not  mentioned  explicitly  in 
the  TCSEC,  some  security  requirements  of  these  types  should 
be  imposed  on  networks.  However,  the  Workshop  results 
indicated  that  the  definition  of  “denial  of  service"  is  mission 
dependent,  and  hence  it  would  be  difficult  to  define  general 
requirements  for  countermeasures  against  it.  Similarly,  while 
communications  integrity  can  be  quantified  statistically,  it  is 
difficult  to  state  universally  acceptable  requirements  for 
transmission  accuracy. 

The  idea  of  trying  to  apply  the  TCSEC  to  network 
components  seems  to  work  well  when  the  component  is  a 
multilevel  host,  but  is  less  plausible  when  the  component  has 
a  more  limited  or  special  function,  such  as  an  encryption 
device  or  a  switching  node.  Even  hosts,  multilevel  or 
otherwise,  arc  not  evaluated  in  the  same  way  for  network 
purposes  when  the  network  connection  is  limited  to  a  single 
security  level,  or  when  the  hosts  lias  special  trusted  functions 
introduced  to  support  the  network  connection. 

Encryption  plays  an  important  part  in  network 
security,  lint  it  is  not  clear  to  what  extent  requirements  for 
particular  encryption  methods,  and  for  the  associated 
software  and  hardware,  can  be  specified  in  a  document 
analogous  to  tin-  Tt'SK/'.  Tin*  reason  for  this  is  the  division 
of  responsibility  between  the  NHSC.  which  is  competent  to 


evaluate  trusted  software,  and  those  parts  of  NSA  ani  other 
organizations  that  are  competent  to  evaluate  cryptosystems. 

LAYERING  SECURITY  POLICY 

There  are  a  number  of  terms  and  concepts  in  the 
TCSEC  that  are  difficult  to  interpret  in  a  network  context. 
Two  of  the  more  troublesome  ones  are  subject  and  object  . 
Even  for  standalone  computer  system  evaluation,  it  is  not 
always  clear  what  the  subjects  and  objects  of  a  system  are. 
Subjects  are  usually  human  users  or  processes;  but  sometimes 
I/O  ports  can  be  regarded  as  subjects.  Objects  are  usually 
files;  but  sometimes  I/O  devices,  temporary  internal  buffers, 
and  subjects  are  considered  to  be  objects. 

in  practice,  subjects  and  objects  are  identified  in  the 
context  of  a  particular  system  in  conjunction  with  the  access 
policy  it  is  designed  to  support.  In  other  words,  the 
interpretation  is  a  judgment  call,  if  it  turns  out  that  certain 
repositories  of  information  have  been  neglected  as  candidates 
for  being  objects,  transfers  of  information  through  them  will 
be  regarded  as  covert  channels.  Since  covert  channel  analysis 
is  part  of  TCSEC  evaluation,  the  situation  is  reasonably 
under  control. 

The  situation  is  more  complex  in  a  network 
environment.  There  are  many  more  options  for  the 
interpretation  of  subjects  and  objects.  Hosts,  nodes, 
gateways,  switches,  front  end  processors,  and  subnets  might 
also  be  subjects:  and  messages,  packets,  virtual  circuits, 
connections,  channels,  links,  headers,  plus  the  new  subjects 
just  named,  might  also  be  objects.  The  prospect  of  devising 
an  access  control  policy  for  an  internet  that  delineates  the 
roles  of  many  of  these  players,  and  performing  a  covert 
channel  analysis  that  takes  care  of  the  ones  that,  were  left 
out,  is  daunting. 


Network 


Figure  1  Are  Theg  All  Network  Subjects7 

A  problem  related  to  the  interpretation  of  subjects  was 
discussed  in  the  Accountability  group  at  the  Workshop,  and 
its  conclusion  hinged  on  the  concept  of  protocol  layering. 
The  group  noted  that  individual  identification  and 
accountability  across  a  network  is  a  service  provided  by  a 
high  layer  of  protocol.  Individual  accountability  is  not 
possible  in  networks  that  only  provide  services  up  to  the 
transport  layer.  A  transpo  t.  service  is  host-to-host;  it  has  no 
way  of  knowing  whether  ;  particular  user  is  receiving  data 
from  a  particular  file. 
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The  point  is  that  whether  a  security  policy  makes  sense 
depends  on  the  service  provided  by  the  network,  as  specified 
by  the  user  interface  to  a  particular  protocol  layer.  The 
binding  of  a  security  policy  requirement  to  a  protocol  layer  is 
quite  natural  in  a  network  context,  and  it  should  provide 
some  insight,  not  only  into  how  to  interpret  policy 
requirements,  but  also  how  to  structure  the  evaluation 
process. 

It  is  not  necessary  to  confine  the  security  policy  for  a 
given  network  to  a  single  protocol  layer  interface. 
Requirements  on  different  layers  will  certainly  be  called  for. 
For  example,  all  information  on  communication  links  should 
be  protected  from  undetected  eavesdropping  or  other 
interference,  by  physical  protection  or  link  encryption.  That 
requirement  clearly  applies  to  the  logical  link  layer  or  below, 
and  exists  independently  of  higher  level  requirements  on 
access  control. 

Stratifying  security  requirements  into  protocol  layers 
lias  the  principal  benefit  of  preventing  interpretations  that 
are  nonsensical,  or  fundamentally  incompatible  with  the  way 
networks  are  designed,  because  they  cross  layers.  It  also  has 
implications  for 

how  to  define  what  a  network  is,  for  purposes  of  evaluation, 
and  how  to  identify  and  evaluate  its  components. 

To  quote  Tanenbaum,  “The  peer  process  abstraction  is 
crucial  to  all  network  design"  [3,  p.  13).  Peer  processes 
communicate  with  one  another  following  certain  rules 
defining  message  types,  formats,  and  conventions  for  various 
activities  such  as  opening  and  closing  connections,  error 
correction,  and  so  on.  In  order  to  send  a  message  to  a  peer,  a 
process  uses  a  lower  protocol  layer,  sending  the  message 
downward  through  an  interface;  and  the  other  process  will 
receive  it  when  it  pops  up  through  the  interface  at  the 
destination.  Although  the  two  communicating  processes  may 
be  a  considerable  distance  from  one  another,  the  interface  to 
the  lower  protocol  layer  forms  a  single  conceptually  global 
shell,  enclosing  a  sjstem  that  is  itself  a  network. 

We  might  visualize  peer  processes  as  heads  of  pins, 
which  are  all  stuck  in  the  same  pincushion.  The  pincushion 
is  hollow,  however,  and  inside  there  is  another  pincushion 
o  mplete  with  pir.j,  whose  herds  form  ihe  shell  ol  the  outer 
one.  Similarly,  the  peer  processes  in  the  higher  layer  may 
support  a  higher  level  network  sen.ee.  We  are,  therefore, 
equating  a  network  with  the  service  provided  by  a  protocol 
layer,  nd  observing  that  networks  can  be  nested  within 
others  y  virtue  of  the  protocol  layering. 

This  layering  of  networks  is  not  merely  an  abstraction; 
network  services  are  actually  built  by  filing  components 
supporting  a  higher  level  protocol  to  an  existing  network. 
This  sort  of  network  construction  suggests  that  the  entire 
existie  ;  network  should  be  thought  of  as  a  sin  It*  component- 
of  the  new,  higher-level  one,  since  it  was  one  oi  the  “pieces’' 
used  to  put  it  together. 


THE  ISO  MODEL 

We  will  matte  usn  of  much  of  the  ISO  reference  model 
terminology  because  of  it-  wide  familiarity.  In  that  model, 
the  architecture  of  a  network  has  seven  layers,  and  those 
layers  will  be  characterize. t  briefly  ''plow.  It  should  be  kept 
in  mind  that  the  existence  of  layeis,  and  the  occurrence  of 
certain  common  t unctions,  are  more  important  than  the 
particular  grouping  of  functions  into  the  ISO  layers.  Few,  if 
any,  networks  have  natural  separations  between  layers  at  the 
exactly  the  same  places  envisioned  by  the  ISO  committee, 
and  many  networks  have  additional  functions  that  do  not 
seem  to  belong  inside  any  of  the  seven  layers,  but  occupy 
layers  of  their  own.  Nevertheless,  the  seven  ISO  layers  are 
helpful  as  a  starting  point. 

Peer 


figure  2  Protocol  Lego  ing 

In  layer  I,  the  physical  layer,  the  peer  entities  are 
simple  transmission  and  reception  devices  sue))  as  modems. 
For  each  of  them,  the  network  is  only  a  single  wire  leading  to 
another  modem.  A  modem  is  also  conscious  of  a  user  who 
communicates  with  it  over  a  connector,  acting  as  a  input  and 
output  for  voltage  levels.  Voltage  levels  at  some  of  the  pins 
on  the  connector  are  simple  commands  to  start,  wait,  etc. 
Security  concerns  at  the  physical  layer  are  limited  to  physical 
protection  of  the  link  medium  from  tapping  nr 
electromagnetic  eavesdropping. 

In  layer  2.  the  data  link  layer,  the  peer  entities  are 
processes  who  see  the  network  as  a  kind  of  two-endod  modem 
(  a  modeniedom?)  that  can  be  used  to  transmit  individual  8- 
bit  characters,  or  perhaps  longer  data  units,  to  a 
corresponding  process  at  the  other  end  of  the  modem.  These 
data  link  processes  may  be  located  in  a  host  or  in  a  si  'urate 
network  interface  unit.  Their  users  are  sources  and  sinks  of 
character  streams.  A  data  link  process  may  have  some 
responsibilities  for  error  detection  and  retransmission.  Link 
encryption  is  typically  applied  at  the  lower  edge  of  the  data 
link  layer. 

In  layer  3,  the  network  layer,  the  peer  entities  arc 
processes  who  see  the  network  as  a  collection  of 
communicating  processes  -  this  is  the  first  layer  that  knows 
tiiat  a  network  has  m>  re  than  two  ends.  Let  us  refer  to  each 
of  these  processes  as  a  “node”.  A  node  understands  that  it  is 
connected  directly  via  data  links  to  only  a  few  oiler, 
neighboring,  nod.  .,  and  often  play.--  the  role  of  a  reiay  station, 
passing  on  packets  received  from  other  nodes.  Its  user,  if 
any,  is  a  host  process.  A  packet  is  a  sequence  of  characters 


with  source  and  destination  addresses,  plus  some  error 
detection  information  relating  to  the  packet  as  a  whole. 
Some  communications  integrity  concerns  are  addressed  at  the 
network  layer. 

In  layer  4.  the  transport  layer,  the  peer  entities  are 
processes  representing  hosts.  A  host  process  is  actually  less 
aware  than  the  layer-3  nodes  of  the  network  topology;  it. 
knows  the  addresses  of  other  hosts,  but  it  doesn’t  know  which 
ones,  if  any,  are  its  neighbors.  The  host  process  divides  its 
user  input  into  packets.  If  necessary,  it  attaches  a  sequence 
number  to  the  packets,  so  that  its  peer  entity  will  know  when 
packets  have  arrived  out  of  order,  and  thus  can  reorder  them, 
and  detect  when  packets  are  missing.  End-toend  encryption 
can  be  applied  at  the  bottom  of  the  normal  transport  layer. 

In  layer  5,  the  session  layer,  the  peer  entities  an- 
processes  whose  users  are  application  programs.  An 
important  function  of  a  session-layer  process  is  to  set  up  a 
connection  by  going  through  a  login  procedure,  which  may 
involve  communication  with  a  peer  entity  in  an  access  control 
center  host.  When  end-to-end  encryption  is  used  with 
automatic  key  distribution,  a  session-layer  process  uses 
transport  layer  services  to  obtain  and  distribute  the 
encryption  key. 

The  two  higher  layers,  the  presentation  layer  (6)  and 
application  layer  (7),  differ  greatly  from  system  to  system,  in 
a  distributed  system,  where  the  user  is  not  forced  to 
distinguish  between  local  resources  and  remote  resources, 
processes  at  these  layers  translate  user  requests  that  require 
remote  resources  into  requests  for  session  layer  services.  Most 
network  security  concerns  are  addressed  at  lower  layers, 
though  end-to-end  encryption  could,  in  principle,  be  applied 
in  any  layer  from  4  to  7. 

in  an  internet  environment,  host  addresses  accepted  by 
tlie  transport  layer  have  a  network  component,  so  that  hosts 
in  other  networks  may  be  addressed.  Internet  communication 
is  accomplished  by  forwarding  packets  from  one  network  t" 
another  via  gateway  hosts.  A  protocol  layer  is  needed  to 
translate  the  compound  net/host  addresses  into  an 
appropriate  host  or  gateway  address  within  a  network.  The 
internet  layer  is  also  concerned  with  fragmenting  and 
reassembling  packets  at  gateways  for  travel  through  networks 
with  different  packet  sizes.  Since  the  internet  layer  is  used  by 
the  transport  layer  and,  in  turn,  uses  the  network  layer,  it  is 
between  layers  3  and  4,  as  described  above,  and  it  is  viewed 
a:;  the  upper  part  of  layer  3. 

2.  A  SEQUENCE  OF  EXAMPLES 

INTRODUCTION 

The  important:..'  of  protocol  layering  in  evaluating 
networks  will  lie  illustrated  uTh  a  sequence  nf  examples 
based  Ions-- ly  on  i.!u  evolving  D1)N  architecture.  We  will  look 


ai  several  networks,  eacli  on  ■  built  on  top  of  a  preceding  one. 
In  each  case  we  will  perform  an  off-tlie-eufT  evaluation  of  the 
network  under  a  reasonable  interpretation  of  the  TCSEC, 
with  respect  tc  compromise  protection.  The  examples  are 
intended  to  bear  a  general  architectural  resemblance  to 
certain  real  networks,  such  as  the  ARPANET.  In  some  cases, 
the  names  of  the  corresponding  real  networks  will  be  used  for 
tiie  examples  to  suggest  the  connection,  but  it  should  al°o  be 
kept  in  mind  that  many  details  and  features  of  the  real 
networks  have  been  omitted  or  altered. 

Security  policy  requirements  will  be  applied  to  the 
network  service  provided  by  the  outermost  protocol  layer, 
while  architectural  requirements  will  be  applied,  where 
appropriate,  to  network  components. 

ARPANET 

We  begin  with  a  simplified  version  of  the  ARPANET. 
The  bash  components  of  this  -ARPANET  are  the  IMPs 
(Interface  Message  Processors,  which  are  switching  nodes)  and 
the  trunks,  providing  a  network-level  liost-to-host  service. 
The  network  provides  discretionary  access  control,  as  required 
for  division  C,  in  the  sense  that  messages  are  delivered 
normally  only  to  the  addressed  destinations.  This  seems  to 
satisfy  the  requirement  for  access  control  at  the  granularity  of 
a  single  host. 

The  discretionary  access  control  requirement  actually 
refers  to  “users”,  but  the  network  provides  only  host-to-host 
service,  so  the  only  proper  interpretation  for  “user”  here  is 
“host”.  Identification  and  authentication  in  the  usual  sense 
are  obviated  with  this  interpretation  for  “user”. 

Looking  at  the  architectural  requirements  for  class  Cl, 
one  could  say  that  the  TCB  (Trusted  Computing  Base) 
operates  in  its  own  “domain”,  since  we  could  include  ail  the 
software  in  each  IMP  in  the  TCB;  there  is  no  “user 
programming”  on  this  system. 

Vet.  this  ARPANET  has  a  serious  security  problem; 
any  individual  could  obtain  information  destined  for  any  host 
by  eavesdropping,  "ia  wiretaps  on  suitable  trunk  lines.  There 
is.  of  course,  no  reference  to  this  kind  of  vulnerability  in  the 
TCSEC.  Should  we  disqualify  this  network  for  division  C,  or 
just  say  that  it  is  good  enough  for  Cl  but  not  for  C2?  One 
way  to  pursue  this  question  is  to  look  at  a  similar  network 
that  addresses  this  vulnerability. 

PRTVATENET 

Suppose  that  link  encryption  devices  are  added  to 
trunks  between  IMPs,  and  at  the  same  lime  we  place  the 
IMPs  into  secure  areas.  The  net  effect  of  these  measures  is  to 
protect  sensitive  information  from  exposure  to  the  outside 
world.  Although  the  host  interface  to  the  network  is  the 
same,  its  link-layer  service  component  lias  been  replaced  with 
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a  more  secure  one.  This  makes  it  a  new  network;  call  it  architectures  suggested  for  a  pre-Blacker  phase  of  DDN, 
PrivateNET.  although  subsequently  discarded.  Let  us  call  it  IPLI-DDN. 


The  most  startling  difference  between  ARPANET  and 
PrivateNET  is  that  'he  latter  could  operate  in  a  dedicated  or 
system-high  mode  with  classified  information,  (assuming  that 
the  link  encryption  system  was  approved)  while  the  former 
could  not,  unless  it  were  a  local-area  network  entirely 
enclosed  in  a  protected  facility.  It  is  true  that  any  standalone 
computer  could  process  classified  information  if  it  were 
enclosed  in  a  protected  environment,  without  raising  its 
evaluation  class.  Nevertheless,  it  is  argued  here  that 
encryption  should  be  regarded  as  an  architectural  feature  of 
the  network  and  not  an  environmental  add-on,  because  it 
changes  the  nature  of  the  service  offered  to  users.  This  is 
perhaps  not  so  compelling  in  the  case  of  link  encryption,  since 
the  associated  encryption  devices  are  relatively  simple.  In 
more  advanced  schemes,  however,  in  which  access  control  is 
interwoven  with  key  distribution,  it  is  clear  that  the 
architecture  of  the  encryption  system  is  a  large  and 
significant  part  of  the  network  design,  with  substantial 
trusted  software,  and  it  must  receive  correspondingly  great 
attention  during  the  evaluation. 


Is  ARPANET  or  PrivateNET  in  class  C2?  Possibly. 
The  requirement  for  "resource  isolation”  suggests  that  special 
provisions  are  necessary  to  prevent  messages  from  getting 
mixed  up  inside  switching  nodes.  It  is  unclear  whether  the 
IMPs  satisfy  this  requirement.  However,  the  software  that 
keeps  messages  separate  is  no  worse  than  the  software  that 
supports  the  discretionary  access  control  requirement  by 
preventing  misdelivery,  so  there  does  not  appear  to  be  a 
reason  to  reject  it.  Another  factor  to  consider  is  the 
maintenance  of  an  adequate  audit  trail. 


Figure  4.  IPU-DDN 


End-to-end  encryption  gives  us  much  greater  assurance 
that  messages  will  not  be  compromised  by  either 
eavesdropping  or  misdelivery.  But  the  network  is  still  only  in 
division  C,  because  it  knows  nothing  about  security  level 
labels.  Given  the  large  amount  of  additional  expense  and 
effort  that  went  into  it.  relative  to  PrivateNET,  and  its 
greater  level  of  protection,  it  deserves  a  higher  ranking. 

With  IPLI-DDN  we  have  network  complex  enough  so 
‘hat  we  need  to  take  a  close  look  at  its  componen-s.  What 
are  the  components  of  IPLI-DDN?  The  IPLI’s  are  certainly 
components;  and  it  is  suggested  that  the  entire  PrivateNET 
be  taken  as  the  only  other  component.  The  TCSEC  has 
security  policy,  accountability,  assurance,  and  documentation 
requirements  for  a  TCB  that  have  implications  for  each 
component.  These  requirements  could  reasonably  be 
supported  by  an  IPLI,  though  some  effort,  and  perhaps  some 
new  documentation  would  be  necessary  *o  establish  that 
claim.  Some  of  the  requirements;  especially  those  relating  to 
accountability,  apply  rather  obliquely  when  a  host  is  a 
network  subject. 

The  PrivateNET  component  needs  to  be  trusted  only 
to  support  discretionary  distinctions  between  hosts  in  the 
same  key  community.  But  this  property  may  be  interred 
from  its  prior  “evaluation"  as  a  network  in  its  own  right. 
This  illustrates  how  certain  short  cuts  are  possible  when  a 
subnet  can  be  regarded  as  a  single  component  of  a  higher- 
level  network. 


IPLI-DDN 

On  top  of  the  PrivateNET  basic  transport  service  we 
can  superimpose  a  layer  that  provides  end-to-end  encryption, 
initially  with  IPLI's  (Internet  Private  Line  Interfaces).  This  is 
a  new  network,  also  with  an  interface  to  a  layer  3  service.  To 
ensure  that  a  message  will  be  kept  secret  from  all  hosts  other 
than  the  desired  destination,  one  arranges  (ahead  of  time)  for 
the  IPLI’s  at  one’s  own  host  and  the  destination  host  to  share 
a  key  that  is  not  available  at  any  other.  Or,  one  could 
arrange  for  group-level  access  control  by  distributing  keys  on 
a  eommuniiy  basis.  This  scheme  is  very  much  like  one  of  the 


DNSIX 

As  an  example  of  a  network  supporting  mandatory 
access  control,  consider  multilevel  security  facilities  such  as 
those  planned  for  DoDIIS  CDoD  Intelligence  Information 
System).  Let  us  assume,  for  our  purposes,  that  DoDIIS  will 
depend  on  IPLI-DDN  for  backbone  communication  over  long 
distances.  A  DoDIIS  node  consists  of  one  or  more  hosts  with 
a  common  interface  to  IPLI-DDN.  DoDIIS  hosts  generally 
handle  compartmented  information,  but  only  some  operate  in 
true  compartmented  mode,  while  others  are  system  high,  slid 
still  others  are  dedicated  to  a  single  compartment. 
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in  each  host,  is  very  much  like  a  protocol  layer.  Distributed 
system  evaluation  is  discussed  further  in  the  next  section. 


Figure  5  DNSIX 

The  network  security  architecture  being  developed  for 
DoDIlS  is  intended  to  support  controlled  acres*  by  users  at 
terminals  to  FTP  and  Tein-t  services  at  remote  hosts.  The 
security  policy  has  implications  for  ( 1 )  restrictions  on  creating 
cross-network  sessions  and  (‘2}  security  labels  on  datagrams. 
The  policy  is  to  be  enforced  by  a  additional  protocol  layer  (or 
layers)  calk'd  DNSIX  (D  o  L)  1  f  s  Network  Security  for 
Information  exchange).  The  DNSIX  software  is  split 
between  each  DoDIlS  host  and  its  associated  NFE  (Network 
Front  End),  which  contains  the  TCP/IP  software. 

When  evaluating  DoDIlS  against  division  I! 
requirements,  the  network  service  wc  are  actually  evaluating 
is  the  DNSIX  interface,  which  provides  the  p-tnote  services. 
The  requirements  for  DNSIX  do  appear  to  match  closely  with 
B  requirements. 

The  components  of  DNSIX  are  (1)  the  DoDIlS  hosts, 
since  they  have  trusted  DNSIX  software;  (2)  the  NITv’s,  since 
they  also  have  trusted  DNSIX  software;  and  (3)  1PL1-DDN. 
Considered  as  components,  each  of  those  has  certain  specitic 
functions  it  must  support,  and  its  evaluation  is  with  respect 
to  these  functions  rather  than  the  overall  mandatory  security 
policy  which  they  support.  While  the  eompartmented  DoDIlS 
hosts  will  probably  be  U-division  systems  with  respect  to  the 
TCSEC,  that  fact  is  not  relevant  to  thiir  evaluation  as 
DNSIX  components,  except  insofar  as  their  architecture 
assures  the  protection  of  the  DNSIX  software  they  contain. 
Similarly,  even  though  1PL1-DDN  is  only  division  C.  it  can  be 
a  component  of  ai.  P  network,  because  its  function  is  only  to 
isolate  connections:  the  mandatory  access  policy  is  taken  care 
of  by  the  DNSIX  protocol  layer. 


it  should  be  kept  III  h 
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BLACKER-DDN 

Another  major  step  in  upgrading  DDN  is  to  use 
Blacker  ror  end-to-end  encryption  instead  of  IPLI’s.  Like 
1PLI-DDN,  a  Blacker-DDN  is  built  by  putting  a  protocol 
layer  on  top  of  PrivateNET.  Blacker-DDN  components 
include  not  only  the  Blacker  Front  End  (BFE)  in  place  of  the 
1PL1,  but  also  a  Key  Distribution  Center  (KDC),  and  an 
Access  Control  Center  (ACC).  The  subnet  component  is 
PrivateNET.  The  functional  advantage  of  Blacker  over  IPLI’s 
is  that  keys  are  distributed  in  such  a  way  as  to  enforce 
security  level  separation  as  well  ns  community  separation.  It 
is  also  more  convenient  because  keys  are  distributed 
automatically  over  the  network. 

Because  Blacker-DDN  enforces  interconnection  rules 
based  on  security  levels,  it  should  be  targeted  for  division  B 
or  A.  In  the  TCSEC.  the  step  from  B  to  A  comes  primarily 
from  the  use  of  more  rigorous  methods  to  verify  that  tne 
compromise  protection  policy  is  upheld. 
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DNSIX 


software  in  a  DoDIlS  host,  may  have  repercussions  on  the 
TCSEC  rating  of  that  host.  For  example,  the  DNSIX  host 
software  may  have  pri'  il  go-  such  as  kernel-domain  access  to 
communications  ports.  11  .-o,  it  is  trusted  not  only  in  the 
network  sense,  but  also  for  the  host  evaluation. 
Receralication  of  the  host  may  be  needed. 

It  is  also  reasonable  to  try  to  evaluate  DoDIlS  itself, 
rather  than  its  network  interlace  DNSIX.  DoDlls  can  be 
regarded  a-,  a  distributed  .-ysiem.  providing  access  to  both 
local  and  remote  -ervic-s.  The  inirrlV.ee  to  the  trusted  part 
of  tie1  sv.'-t'-in,  which  should  b>-  identical  to  the  it  il  interlace 


Figures  Blscker-DDN 

Suppose  for  a  moment  that  the  additional  verification 
effort  were  not  made  to  raise  Blacker-DDN  from  B  to  A.  We 
would  then  have  two  networks,  Blackcr-DDN  and  DNSIX. 
both  in  U,  but  with  significant  architectural  differences 
between  them.  Although  Blacker-DDN  and  DNSIX  boll) 
support  a  mandatory  access  control  policy,  the  special 
Blacker  components  will  be  designed  with  more  attention  to 
the  separation  of  security-critical  modules  from  the  rest  of  the 
system.  Another  way  of  summarizing  the  difference  is  to  say 
•.hat  Blacker  components  can  he  evaluated  under  the  d  OSLO 
as  B3  or  At  systems,  while  the  DoDIlS  hosts  mid  NFE's  are 
probably  only  B2  at  most.  This  means  that  there  are 
environments  (or  distributed  systems)  for  which  Blacker 
would  be  satisfactory  and  DNSIX  unsatisfactory.  This 
suggests  that-  it  is  reasonable  to  maintain  the  distinction 
between  B2  and  B3  in  a  network  context  on  the  basis  of 
architectural  requirements,  so  that  Blacker-DDN  could  be 
distinguished  from  DNSIX. 


AUTO-DDN 


Tlu-rt’  is  ;m  alienin'  'vr  I < >  using  <  n«'-t  i >-«■! i« i  ener ypt  inn. 
We  could.  instead.  upgrade  IVivaleNKT  nv  replacing  the 
IMI’s  by  vpc  mil  packet  switching  nodes  (I'SW)  that  inspire 
greater  eoiilidence.  by  virtue*  of  their  architect  urc  ami 
deveh  Jpliieill  en  viromii'-nt .  They  might.  lor  example,  contain 
.security  kernels  and  be  evaluated  under  the  TObX‘  M  a 
relatively  hia.lt  level,  perhaps  even  Al.  Let  us  call  this 
hypothetical  network  Al:TO  DDN:  it  U  reminiscent  of 
AUTODIN  II.  whose  developiucti!  was  discontinued  in  favor 
of  DDN. 

AUTO-DDN  U  not  built  on  top  of  cither  i ’rival  cNKT 
or  AKUANKT.  Like  JhivateNKT,  it  is  built  on  an  ciicn  ,  *  1 

link  layer.  The  components  of  AUTO-DDN  are  the  PSN’s 
mid  t ho  link  layer.  IF  it  were  evaluated,  its  rating  would 
depend  on  the  functionality  and  architecture  of  the  PSNs. 
Let  us  suppose  that  the  I’S.Vs  support  mandatory  access 
controls,  so  that.  say.  a  Secret  datagram  will  be  delivered 
only  to  a  host  accredited  for  Secret  information. 

If  we  compare  AlTO-DPN  to  hlack'T-DPN,  they  are 
similar  in  the  quality  of  their  components,  but.  there  is  a 
striking,  dillereme  in  the  protection  of  message  data  in 
switching  nodes:  it  is  protected  by  end-to-end  encryption  in 
Mlaeker-DDN  IMPs.  while  it  is  in  the  clear  and  protected  only 
bv  the  operating  system  access  controls  in  AUTO-DDN 
PS. \'s.  This  is  certainly  a  large  enough  increment  in 
coinpromi.se  pmtectio’-  to  warrant  evaluating  Blacker-DDN  at 
a  higher  rating. 

Comparing  AUTO-DDN  with  DNSIX  is  more  dillicnll: 
we  see ni  to  be  comparing  apples  and  oranges.  Since  DNSIX 
is  built  on  IPLI-DDN,  ii  provides  end-to-end  encryption  of 
message  dat  a  in  IMPs:  but  AUTO-DDN  PSN's  employ  a  more 
trust  won  by  arc-hit  emme  f  by  assumption)  than  the  DoDMS 
hosts  and  NT’K’s  with  their  DNSIX  software.  The  crucial 
obseivation  Imre  is  that  flu*  tint,  is  still  in  tin*  clear  while'  in 
the  PoUIlS  hosts  and  Xl’K's;  the  HM.I's  provide*  only 
community  isolation,  t  onsi-cjucnt ly .  the  risk  of  mislabelling 
message  data  D  greater  m  DXs'lX.  I  Ills  argument  supports 
the  coniem  i.  ii  r  |, at  DNSIX.  AUTO-DDN.  and  Mlacker-DDN 
(before  \ eri Jieat ii >u )  «'\em plil’y  three  elasM-s  within  division  Ii. 

3.  DISTRIBUTED  SYSTEMS 

INTRODUCTIOX 

One  of  the  e« uiundi  mus  ii'-rii- -  .  d  at  i|i'-  Workshop 
Was  w  lid  1;ii‘  In  think  oj  :i  ip-Iw-tK  as  simply  a 
eoimn  •  i  ni  c:  1 1  imr-  service  joining  i  1 1«  1«-|*» -f  i«  i*  -  >  1 1  ho-.i or  as  a 
distributed  sv  ->t  t  m  into  which  bos!'.  ale!  «  i  •iiitau'iu  at  'ons  are 
integrated. 

'Pin-  i  •'  i  in  di"i  ii  but  •'.!  SV-!  eiii"  is  noi  muilv  reserved  l**r 
a  network  that  oilers  a[>pli‘ ">ti. -u-la\ f-r  sfi\i«i^,  and  fntiliob- 


aceess  to  both  local  and  n*  me  Me  resources.  DoOllS  and 
SACDIN  ai  '*  examples  of  distributed  systems.  At  I  lie  smaller 
end  of  the  scale,  there  are  di  lli hilled  systems  on  local-area 
networks  (LANs).  There  arc  many  examples  of  workstations 
on  a  LAX  sharing  a  global  iil"  system,  in  which  a  iile  located 
at  niiotli'T  work-nation  or  a  Iile  server  ran  he  loaded  as  easily 
as  one  stored  locally. 

The  term  “diM ri  hilled  system”  ran  also  hi*  used  in  a 
broader  sense  to  apply  to  a  in  network,  incisive  of  the  hosts 
lhai  are  connect -d  to  ii.  It  is  cornenicni  for  us  to  use  the 
term  in  this  broader  sense,  since  we  have  restricted 
“network”  to  mean  a  protocol  layer  interface.  In  t  his  section 
we  will  look  at  concerns  that  arise  from  the  way  hosts  are 
eoimcct.cd  to  networks  to  form  distributed  systems. 

In  a  "Inif”  distributed  svsUmu,  network  access  to 
remote  resources  is  viewed  a.s  an  extrusion  of  I  lie*  local 
resources  provided  by  each  host.  It  was  stressed  earlier  that- 
a  global  network  security  policy  should  be  stated  in  the 
context  of  the  ser.ier  interface  to  one  or  more  ’protocol  layers. 
SO  that  the  appiopriate  subject",  objects,  and  access  control 
requirements  ran  be  idciitilic*d.  When  thinking  in  terms  of  a 
distributed  system  that  manages  both  local  and  remote 
resources,  we  should  still  be  able  to  i den t j fv  a  chsti  ibutiul 
s erner  iutvifatc  in  terms  of  which  to  slate  the  policy,  even 
though  it  is  not  strictly  a  piotocol  layer  interface. 

For  true  distri butt'd  .systems  it  is  reasonable  to  follow 
our  general  prescription  tor  applying  the  TCSJOC-  h>  networks: 
apply  security  policy  rcquireuunls  ia  t.lic  global  interface,  and 
architectural  requirements  to  the  components,  including,  in 
this  case,  the  hosts.  Hut  the  implementation  of  this  approach 
will  not  be  smooth  sailing  The  principal  diliieullv  will  be  in 
deriving  its  implications  for  non-host  components. 

COMPONENTS 

It  will  be  necessary  to  limit  security  policy 
recpiinMiieui "  of  non-lu’-t  component  to  match  t.’neir  specific 
fuii't  ions.  'Ihi-  design  "pceilieat  ion  and  verification 
mpiirviiu  nis  for  ditisioli  li  and  A  com poiieuts  call  be  seen  as 
limited  to  srrurils  properties  needed  t  c »  support  a  global 
policy  fbis  means  excluding  TCSKC*  requirements  lor 
"••eiintx  labels  ihat  may  be  inapprop.riat e  for  some  trusted 
<  oin j.onenis.  A  *-wii filing  nod»  .  for  example,  must  be  trusted 
to  sepal  ;it  I*  MIC  - -ages  from  one  a  no  I  1 II- r.  and  pre\’c|it  message 
data  from  leaking  into  headers:  bill  i*  can  do  so  with  im  need 
to  m  ai  tit  ain  senility  label-. 

The  perspective  < -.pousrd  in  this  paper  suggests  that  it 
Would  be  vcr\  desirable  t-»  \ir\v  subnets  av  coin  poiiec i  :  the 
problem  is  i  hat  T(  SU(  ‘  aceliit  ee|  lit  :d  requirements  at-  r*  ally 
applicable  only  It?  standalone  computers.  As  an  expedu  id 
one  iiiigli'  s  i\  [.bat  .  wlmn  a  distributed  system  is  built  on  lop 
of  a  siil.i]>-i.  Id  -  1 ’ri\ at  e\K  I  or  ll’l.l-DDN.  : » 1 1  of  I  ]  i » ■ 
rum  pom  ni-  • -f  lb  •  subnet  [and  all  of  then  »'€»tii pone nt s.  de.) 
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are  c'n'Vuti-i!  it.  f  l.e  status  of  n  tin  poni-jits  <  »S"  ill**  dNt  rihuTed 
system.  *lc>\\  n  to  i-\  »*p‘  IMF.  and  m.  h-m:  1ml  it 

uoiiM  lit-  rtinn-jii  ur.Sly  i.  and  mop-  1 1 ;  tun.-  with  tin- 

precepts  o|‘  iietvvoik  -i !*r]ii if-.  1 11  n-,  it'  i  li-il  wriv  mil  iiecessm'y. 

Tin*  above  considerations  suggest  1 1; :\t  *-po<*i:i l 

requirements  should  In-  «1»  \ -■!< .pe-l  fur  various  specific  i yjn->  of 
compoiie  nts.  i 1 1 f ■  1  u 1 1  i 1 1  subnets.  Securit  y  policy-rclat  ed 
requirements  and  architectural  requirements  would  both  lx* 
tailored  for  the  typ1*  of  component. 

Having  s(ap;ir:it i*  requirements  t'or  * li tV**i flit  kinds  of 
(*r  Miipouents  could  a  No  t'ncilit  :iti  ;i  im>re  detailed  consideration 
of  tin*  security  features  appropriate  for  them.  It  might 
become  practical  to  implement  tin*  recommendation  of  the 
Components  Group  at  tin-  Workshop.  nnm<ly.  to  rate 
di Herein  features  at  dith-reni  assurance  levels.  A  liuk- 
eiicry pted  win*,  for  example.  u>  a  -m  1  mot  mmpnneiit .  provides 
li<wt-«:.:*:iniilarit y  dNrrel ionary  security  (:•  ('-division  feature) 
with  ati  extremely  Kils^li  (A--liv Finn)  assurance. 

COMPLEX  SYSTEMS 

A  host  attached  to  a  network  has  se)u/ophr<  nic  roles 
as  a  provider  of  hot  ii  |m,:il  si-rvii-rs  and  network  services. 
True  distributed  systems  integrate  host"  coherent  ly  into  t  lie 
network,  hut  in  others  the  network  connection  N  an 
nft.erthoug lit .  In  the  latter  ca-e.  it  may  b“  impractical  to 
identify  a  dNt ributed  system  -i-rvice  interface  that  supports  a 
coherent  securits  policy. 

‘■''tents  like  SACDIN  am!  I-S/A  WIPE,  whose  hosts 
■ :  arehifeel  me  and  evaluation  fating,  can 

:  ■  ■  a  •-*  > y  1..  I  to  support  a  i-oh'-n-nt  'doled  security 

c:n  f.  'anted  as  1  rue  distributed  systems. 

Mr-  d  i  v  'out  complex  systems 

1  ‘  i::ul  :r  i:  ’  1  •••»  -dual ion  ‘  la^es. 

-  •  ■  m  :  .  1  !  !"•  p*  issj } »le, 

■  ;  \  1  i  •  -\l  e  w  it  I:  a 

•  r  ;  .  ‘  •  n >ii!n  r:  i-  .ji.  given 

i-v  !  :  .  •  1  :i  *  ei  *vit  liiu  t  In- 

-dl'-s  the  mind  to 

'  :u •;  ■ ' . .  ’ . ri r  y  p-Tuy  t  hal 

.  * t-t - »■  :u-  multilevel  host. 

■  r .  ••«  ■  '!*.  h""t  granularity, 

a.  •  •  •  darby  wiihin  «-a»*l: 

of  t  lie 

d  N  our  ’  si  ..  -:.i  l  *|e\  Msji’H!  should 

tioi  1  evaluated  a  t  r.|  s\«,|i*iij,  with  :m  overall 

It  S|\(  evaluation  In  •  should  look  at  it  as  a 

r< ill i *i- 1 i'  <| i  i  ;t  * e»"t  •  wjlh  a i  i  p a ra t el \  eva ! t ia  1  i-d 

ielwoik  service,  t  li  • ! « -  r  I  In- --<■  t-ii  .i-i:,  -1  :n;«a*s.  I  ii*-  appl't»pri:ite 
*4'  oil  i  I*)  e\  inline  lie  Me  h  \  i> !  i  ■ :  ■ !  Iio-i  and  m-lw-rk  evaluation 
i  ■’  I  i  ng-,  in  f-rl'-r  to  i  1 1  - 1 1 1  y  *  -*  •  i » 1 1 : 1 1 1  <  -  d  u<  i«  dj  t  at  i  m  o|  l  in¬ 


hosts  for  their  current  mode  of  operation,  in  the  face  of  their 
attachment  to  the  network. 

The  environments  guidance  document,  associated  with 
the  TCsKC.  called  the  “Yellow  Book"  [*|],  addresses  the 
relation  In-tween  the  evaluated  ratiim,  of  an  AOP  system  and 
*  he  ran-e  of  elas-.ifed  inforiunliou  it  can  handle,  on  the  basis 
of  cimracLcrisiies  of  its  environment,  such  as  the  minimum 
t  oaranee  of  users.  An  analogous  document  addressing  the* 
i  -ues  associated  with  connecting  a  host  to  a  network  is 
currently  being  developed  by  the  N0$0  with  support  from 
MITRE. 

THE  CASCADING  PROBLEM 

An  example  of  an  accreditation  Nsue  that  needs  to  be 
considered  in  a  complex  system  context  wa>  brought  up  by 
Steve  W  :ilki*r.  Suppose  that,  two  ADP  \Vslems  are  operating 
ill  controlled  mode  at  two  adjacent  security  levels,  but  one 
has  the  range*  TS-S  and  the  other  has  the  range  S-C.  They 
could  be  connect «•<!  by  a  trivial  network  consisting  of  a  single, 
physically  p rot c* led  wire  joining  S-level  ports  on  both 
systems.  Tltf  problem  is  that  the  network  connection  has 
created  a  rNk  of  introducing  TS  infoi mation  into  the  C--S 
system,  whose  accreilit alion  only  (pralilics  it  to  handle  the 
two  lower  levels. 

From  the  point  of  view  of  tiic  TCSEC-.  the  network 
ci-unection  has  merely  introduced  a  single- level-S  rosoucT  to 
both  host v.  \\i  rn'U  software  has  been  added  to  either  unst, 
so  their  ('valuation  classes  have  not  been  allectctl. 


Figure?  The  Cascading  ProMem 

What  went  wrong?  Evidently,  the  environment,  of  the 
hosts  i'll ; i ugei  1  by  cc ui neit i ng  them  to  the  network.  We  could 
say  that  the  set  of  human  users  was  expanded,  but  there  is  a 
more  prcrNi*  wav  of  rlmract cri/ing  the  problem,  relating  to 
the  t  rust  wort  hiiiess  of  security  labels  placed  by  a  computer 
system  on  r!.\ssilird  objects.  |n  g«*nernl.  the  object  level  is 
ib  t  rftaim  d  from  t  wo  inllin  tiers; 

Oh}1  ct  l.rrrl  Snmrr  I, m  l  {■  (  'untrihnt ions 

When  iiif*  ■rin :it ioa  niti-r*'  the  systeiu  Irom  outside,  the 
security  level  nf  ib  muikt  is  known  mid  trusted.  Thereafter, 
while  inforiu.it  ion  i-  held  within  tin-  system,  the  correct  level 
is  niaiiit ained  h\  s\st(.in  software.  When  computations  cause 
information  'o  llow  into  an  objeci  from  another,  -‘ccess 
eontrols  eif  lire  that  till  level  of  the  ol»j‘  et  rcinaiiis  ec  insist  cut 
wit  1 1  lb--  lev*  I  of  inli  srmat  i>  >u  e. -at  i 'iluii  e.l  to  it  by  those 
•  >m  ;.i;t  a  i  i •  ill  ' . 
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T*io  I'CSKC  idling  n|'  :i  -AMcm  F  :i  mesiMin*  of  1  hr 
trust  wort  lii  1  u"-*—  of  •'•vstmi  sofiw:u-i-  in  maint  niniug  object 
levels  during  eomiiiUntions:  hut  lu»\\  tnM  worthy  is  the 
del  enilinntioii  of  miiiitc  levt'V  lit  :\  *4  :it;.|:ilone  ADF  system 
environment,  the  normnl  e\terti:il  -c  Hirer  nf  infoniint ion  K 
huiium  users.  If  a  lninian  us  r  s;tys  that  eer»ain  input 
iiifoninuioii  is  Secret,  high  couti-lenee  may  he  placed  in  that 
assignment.  For.  if  tiio  int  is  only  cleared  to  Secret,  he  does 
not  have  ;i n\  higher-level  information  to  introduce:  ami  if  lie 
is  cleared  to  a  higher  level,  he  ran  he  trusted  to  give  the 
proper  level  for  information  m  ihat  le\  e|  m*  lower. 

When  an  ADI’  system  is  conneeted  to  a  network.  I  In- 
network  litroiuis  a  new  source  of  information,  and  it  often 
cannot  he  trusted  to  the  extent  i  hat  human  users  are.  'Phis  is 
one  point  that  must  h<  taken  into  couMdrrnl ion  when  writing 
an  him  iron  men  ts  document  for  ml  works,  or  a  distributed 
system  evaluation  guide. 


A  similar  prohhiu  can  occur  even  for  a  standalone 
system.  Again,  consider  the  two  mut  rolled-mode  systems, 
one  at  TS-S  and  the  other  at  S-C,  hut  do  not  conned  them. 
(  an  we  make  a  tape  on  the  higher-level  system  with  S-Jevel 
files  on  it.  am!  carry  it  to  the  lower-level  system?  No. 

because  the  tape  is  an  external  source  of  information,  ami  its 
security  label,  determined  l.y  tin*  other  controlled  mode 
system,  cannot  he  trusted  any  more  than  if  tlu*  information 
cairn*  across,  a  wire.  Such  a  tape  transfer  would  be 

permissible  only  if  a  responsibi*-  individual  has  reviewed  the 
material  on  the  tape  and  continued  the  correctness  of  its 
marking,  or  ii  the  tape  was  produced  on  another  system  that 
did  not  handle  higher-level  information. 

Problems  like  this  can  he  M*.|\rd  bv  imposing 

additional  restrictions  on  iutcreonmetion.  For  example,  as 
Wnlh'-r  has  suggested,  one  can  insist  that  all  mutually 

connected  systems  < 'penning  o\»T  the  same  M/e  seeiirjiv  level 
rang*  (two  adjacent  levels,  in  the  .-xainple)  share  the  xiim* 
maxi  mum  le\  '  I. 

W  hell  all  aecr.-dit  ilig  agency  wishes  |{]  place  ui'  -r* 
severe  rest  riot  h  ms  nn  certain  information  than  called  for  bv 
normal  environmental  guidelines,  tlie  natural  approach  would 
be  to  s.-t  up  a  community  of  hosts  satisfying  the  tighter 
rest  fictions.  r  <  ,,i, .  nunii  i,s  iik--  I’uis  «-:,ii  i»c  impl'Miimi  ru  bv 
discret  ionary  an-c^  i-nntrn|>  or  em-ry  p! ion. 


4.  SUMMARY 

•  I’ii  it*  ii-f  >1  lay «  ring  is  imp*  »n  aist  in  network 

archil *  rt  u h  .  and  ii  has  n  in-.eipu  in  !  -  for  m  lwork 
e  \  .  1 1 1 1  ‘  1 1  i  Ml.  \  III  I  Will;  is  \  i*  Wi-d  :i^  a  vh  »hal  si-p  ire  |«r<A  ide«l 
by  ih*  use,-  i sit  i  r!  ace  i  r  >  ii  s  <  *ut . - r i : i«  ■  a  pi ■  *  <  >1  lay  *r. 


In  attemptin'*.  f«i  usf 
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requirements  to  Mu-  net  work  globally,  and  architectural 
requirement -  to  tin*  network  components. 

•  Network  globe '  security  policies  should  lie  stated  in 
t r-rms  o|  concepts  supported  1  -  v  a  particular  protocol  layer. 
Uri|tiircmiMits  on  more  t'yiu  one  layer  may  he  called  Tor.  The 
"lohal  policy  has  imprentions  for  derived  functional 
requirements  on  individual  components,  to  support  it. 

•  Pxamples  of  networks  providing,  varying  features 
and  levels  of  assurance  have  suggested  that  the  use  of 
encryption  should  be  regarded  as  an  architectural  feature  of  a 
network,  nltccting  the  evaluation  class. 

•  Separate  requirements  documents  or  appendices 
should  bo  published  for  specific  types  of  network  components. 
In  particular,  it  should  lie  possible  to  consider  entire  subnets 
as  network  components.  I  C'Sh.C1  retptiroint  nts  need  radical 
reinterpretation  for  application  to  components,  so  that  they 
do  not  exclude,  or  place  unreasonable  requirements  on, 
specialized  components  or  subnets.  Component  evaluation 
could  assign  separate  assurance  levels  to  various  features 
appropriate  for  the  component. 

•  A  true  distributed  system  has  a  global  user  interface 
"hose  security  policy  can  be  evaluated  by  the  TCSi’.C. 

•  C  oitiplex  distributed  systems  consisting  of  dissimilar 
hosts  arc  not  practical  to  evaluate  as  true  distributed 
systems.  Instead,  the  goal  of  evaluation  for  such  systems  is 
twofold:  to  evaluate  the  network  itself,  anti  to  justify 
continued  accreditation  ol  the  hosts  for  their  current  mode  of 
operation  niter  at i achincut  ol  the  network.  An  environments 
document  is  needed  to  facilitate  this.  The  fact  that  a 
network  brings  new.  less  trusted  sources  of  information  to  a 
host  is  an  important  environment  til  consideration. 
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"Smart"  Terminals  for  Trusted  Computer  Systems 


by  Hark  D.  Gabriele 
Abstract 

"Smart"  terminals  are  increasingly 
popular,  as  they  can  increase  individual 
productivity  immensely.  However,  such 
terminals  are  not  presently  desirable  from  the 
point  of  view  of  building  a  secure  multi-level 
computer  system,  as  they  open  avenues  for 
spoofing,  covert  channels,  and  relabeling  of 
sensitive  data.  This  paper  is  an  overview  of 
the  problems  and  the  possible  solutions  to  the 
problems  created  by  using  "smart"  terminals  in 
trusted  systems.  Among  those  solutions  are: 
1)  don't  use  smart  terminals;  that  is, 
restrict  trusted  systems  to  "dumb"  terminals 
exclusively;  2)  use  only  terminals  which  are 
"conf igurably  dumb;"  3)  alter  existing  "smart" 
terminals  to  remain  "smart"  vnile  becoming 
"trustable;"  and  4)  use  secure  workstations  as 
"smart"  terminal  emulators.  Each  is  examined 
ana  weighed. 


Introduction 

The  user  community  has  recognized  a  need 
for  some  method  of  accessing  secure  systems 
which  will  increase  individual  productivity. 
This  is  accomplished  on  non-secure  systems  by 
the  use  of  "smart"  terminals.  This  paper  will 
focus  on  what  types  of  terminals  may  be  used 
for  accessing  secure  host  systems  without 
jeopardizing  their  security.  Perhaps  some  of 
the  types  of  secure  terminal  mentioned  here 
will  be  researched  and  developed,  and 
eventually  integrated  into  the  secure  systems 
of  the  future 

These  several  generic  types  of  terminal 
range  from  "dumb"  to  "smart"  to  the  secure 
workstation  of  the  future.  The  advantages, 
drawbacks,  and  security  relevant  aspects  of 
each  will  be  discussed.  Methods  for  securing 
each  type  of  terminal  will  be  suggested,  as 
well  as  possible  problems  which  may  need  to  be 
overcome.  The  end  result  will  be  that  the 
reader  will  have  some  idea  about  the  state  of 
secure  terminals  today,  and  where  they  may  be 
going  in  the  future. 

There  are  some  matters  which  are  not 
addressed  in  this  report.  The  foremost  is 
emanation  security  (the  Tempest  problem) . 
Other  exceptions  will  be  mentioned  as  they 
occur. 

Disclaimer:  The  views  expressed  in  this 
paper  are  exclusively  those  of  the  author 
based  on  experience  gained  as  a  commercial 
products  security  evaluator  at  the  National 
Computer  Security  Center  (NCSC) .  This  paper 
does  not  necessarily  represent  official  policy 
of  the  National  Computer  Security  Center. 


Terminology 

Before  beginning  this  discussion,  a  number 
of  definitions  are  in  order.  First,  we  need 
to  define  o  *r  conception  of  a  "smart" 
terminal : 

A  "smart"  or  "intelligent"  terminal  is 
a  terminal  which  possesses  some  form 
of  volatile  or  non-volatile 
programmable  memory,  and  allows  the 
host  system  to  perform  read  and  write 
operations  on  the  data  in  that 
memory .  1 

In  contrast,  a  "dumb"  terminal  has  no 
programmable  memory.  A  "conf igurably  dumb" 
terminal  is  a  unit  which  may  have  unlimited 
data  processing  and  storage  capabilities,  but 
these  can  be  disabled  to  render  the  machine 
"dumb,"  according  to  the  above  definition. 

A  "trustable"  terminal  is  considered  to  be 
a  device  which  can  be  relied  upon  to  relay  to 
the  user  exactly  what  was  received,  transmit 
exactly  what  the  user  entered  for 
transmission,  and  to  provide  separation  across 
all  security  levels.2 

With  these  definitions  as  a  basis,  there 
must  now  be  a  distinction  made  between  what 
constitutes  a  terminal  and  what  constitutes  a 
network  node.  If  such  a  distinction  is  not 
made,  then  one  can  simply  argue  that  any 
intelligent  terminal  attached  to  a  host 
constitutes  a  network,  and  should  be  dealt 
with  as  such  from  a  security  standpoint. 

An  explicit  definition  of  "network  node" 
is  needed  to  alleviate  this  problem.  Owing 
to  the  increasing  complexity  of  computer 
networks,  a  node  is  a  difficult  thing  to 
characterize;  but  for  the  purposes  of  this 
paper,  a  node  is: 

"A  device  which  provides  CPU  cycles  in 
support  of  some  activity  which  is 
invoked  at  some  other  point  on  the 
network. " 

Where  a  network  is  simply  defined  as  an 
interconnection  of  two  or  more  nodes. 

Note  that  while  a  personal  computer  may 
physically  be  able  to  comply  with  the  above 
definition,  should  this  capability  be 
neutralized  or  defeated  by  some  mechanism, 
then  that  unit  is  no  longer  acting  as  a  node. 
As  an  example:  if  a  personal  computer  is 
running  a  communications  package  which 
includes  a  file  transfer  protocol,  that 
machine  is  acting  as  a  terminal,  not  a  node, 
until  such  time  as  the  host  requests  that  file 
transfer  protocol  is  activated  and  the  machine 
enters  server  mode.  At  that  point,  the 
personal  computer  is  providing  support  to  a 
remotely  activated  activity  (file  transfer,  in 
this  case),  and  is  considered  to  be  a  node. 


1  As  appeared  in  response  147  in  the 
DOCKMASTER  computer  system  Criteria  Discussion 
forum,  entered  by  Vidmar.CPE. 
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Dumb  Terminals 


The  first  coi,f iguration  which  will  be 
addressed  is  that  of  "dumb"  terminals.  These 
are  secure  simply  because  they  have  no  means 
by  which  they  could  compromise  or  subvert 
sensitive  data.  This  type  of  terminal  is 
exemplified  by  the  generic  term  "glass  TTY," 
although  many  types  of  printing  terminals 
would  certainly  qualify.  A  truly  dumb 

termin  '  would  include  no  buffer  memory, 
altho  .a  .a  .y  contemporary  terminals  which  are 
conL;o-  to  be  dumb  do  contain  some  memory. 

Just  ,j‘.  e  a  terminal  is  considered  to  be 

dumb  (1  e  NOT  mean  that  it  must  be 
incon'  ?nient  or  cumbersome  to  work  with; 
however,  any  "intelligence"  which  the  terminal 
exhibits  must  be  provided  by  the  host  machine. 
This  requirement  severely  limits  the  utility 
of  a  dumb  terminal.  All  dumb  terminals  suffer 
from  similar  problems,  to  varying  degrees, 
regardless  of  their  apparent  intelligence  at 
their  user  interface. 

One  drawback  is  that  of  independence  of 
components.  When  working  with  a  dumb  terminal 
which  must  rely  on  a  host  for  ever,  the 
simplest  of  chores,  all  work  must  be  done 
while  the  user  is  on-line  with  the  host.  This 
creates  dependence  on  one  central  host;  should 
that  host  fail,  or  suffer  from  poor  response 
time,  the  user  is  unable  to  work.  Entire 
offices  or  even  corporations  can  be  stymied  by 
a  host  failure;  if  all  computing  is  done  via 
dumb  terminals,  NO  work  can  be  done  on  the 
terminal  until  the  host  service  is  restored. 

Hosts  which  support  a  generous  user 
interface  on  a  dumb  terminal  may  unfortunately 
be  slowed  by  processing  delays.  The  host 
processor  may  incur  a  great  deal  of  overhead 
doing  menial,  terminal-support  tasks,  slowing 
system  response;  again,  user  productivity 
suffers.  Even  the  best  dumb-terminal  systems 
have  these  faults. 

Examples  of  jevy  popular  uumb  terminal 
systems  may  be  found  in  many  configurations  of 
the  IBM  3 2 7x  series  of  terminals  and  terminal 
control  units.  The  3278  terminal  supports 
very  limited  local  functionality:  basically, 
only  the  ability  to  position  the  cursor,  and 
send  up  to  one  screen  of  information  back  to 
the  host  at  a  time.  Virtually  no  processing 
of  the  data  is  done  locally;  although  there  if; 
some  slight  local  intelligence,  the  3278 
terminal  is  essentially  dumb.  The  3274  (and 
related  type)  device  controller,  while 
supporting  error  detection  and  correction, 
does  not  add  to  the  local  functionality  of  the 
terminal.  Almost  ail  terminal  support,  such 
as  buffered  screen  memory,  various  screen  set¬ 
up  options,  etc.  must  be  done  by  the  host. 
The  host  software  support  for  the  terminal 
must  thi  refore  be  trusced  code  in  order  for 
this  coni iguration  to  be  considered  secure. 
Even  though  this  arrangement  does  provide  some 
of  the  functionality  of  a  smart  terminal  with 
few  security-relevant  drawbacks,  it  is  obvious 
that  it  is  not  the  most  economical  method  in 
terms  of  host  CPU  time,  in  addition  to  the 
disadvantages  listed  above. 

All  HC5C-eva luated  systems  require  the  use 
of  "trusrable"  terminals  in  their  evaluated 
configurations.  Dumb  terminals  are  considered 
.intrinsically  si  ■  e  because  they  cannot  aid  a 


malicious  user  in  attacking  the  system  by  any 
known  means.  They  are  therefore  defined  to  be 
"trustable".  They  also  t>'nd  to  offer  fewer 
features  than  contemporary  computer  users 
would  like.  However,  at  the  present  time 
there  are  no  "trustable"  smart  terminals.  So, 
the  user  of  a  secure  computer  system  must 
currently  use  a  dumb  terminal  in  order  for  the 
system  to  remain  secure. 


Configurably  Dumb  Terminals 

The  modern  user  of  a  secure  system,  in 
order  to  have  his  system  running  in  its 
evaluated  configuration,  may  need  to  have  two 
separate  devices  on  his  desk:  a  terminal  for 
communications  with  the  host  machine,  and  a 
personal  computer  for  use  with  spreadsheets, 
word  processors,  etc.  This  tends  to  be  an 
impractical,  as  well  as  an  inconvenient 
solution,  so  in  many  instances,  a  personal 
computer  (PC)  may  be  used  as  a  terminal 
device.  This  is  normally  accomplished  by 
running  some  type  of  terminal  emulation 
software.  Regardless  of  the  software  being 
run,  this  is  almost  never  a  secure 
con  ration.  Too  many  possibilities  of 
sub  .ion  exist:  the  PC  can  "spoof"  a  user 

into  divulging  his  or  her  password,  keep  a 
record  of  the  entire  conversation  with  the 
host  for  later  retrieval  by  another  party, 
open  enormous  covert  channels,  relabel 
sensitive  data,  or  destroy  any  trusted  path 
which  may  exist.  Unfortunately,  great  numbers 
of  PCs  are  being  used  as  terminal  emulators; 
so  some  action  should  be  taken  to  render  them 
secure  enough  to  be  used  as  trusted  terminals. 

The  path  by  which  this  may  be  done  is  to 
render  them  "configurably  dumb."  What  this 
means  is  that  the  user  may  invoke  some  action 
which  causes  the  PC  to  lose  those  things  which 
make  it  untrustable.  As  an  elementary 
example,  one  may  install  an  extra  processing 
card  in  a  generic  PC  which,  when  activated, 
causes  the  machine  to  reboot  from  a  trusted 

ROM  on  that  card,  and  immediately  execute  a 

trusted  terminal  program,  also  contained  in 
ROM.  When  the  card  is  active,  the  personal 
computer  functionality  of  the  PC  is  gone;  it 
is  only  caoable  of  acting  as  a  terminal .  That 
terminal  will  be  trusted  at  the  level  of  the 
software  and  hardware  modifications.  It 
should  be  a  goal  of  the  NCSC  to  develop 

component  evaluation  criteria  which  can 
address  machines  of  this  ilk,  as  they  would 
allow  the  user  to  fashion  his  PC  into  a 
trusted  terminal.  This  terminal  could  be 
either  smart  or  dumb.  If  it  is  to  be  made 
sinai  t,  then  it  will  be  covered  by  the 

discussion  of  smart  terminals  which  follows; 
if  it  is  to  be  made  dumb,  then  it  must  exhibit 
none  of  the  functionality  of  a  PC;  it  must  be 
trustable  in  exactly  the  same  manner  as  any 
other  ciutub  terminal.  Note  that  switchably 
rendering  an  expensive  computer  incapacitated 
except  fer  basic  terminal  emulation  functions 
may  sound  somewhat  ludicrous;  but  if  a  dumb 
terminal  is  all  that  is  needed,  it  may  be  more 
economical  to  arrange  to  equip  a  PC  with  such 
a  device,  so  that  it  may  serve  both  stand¬ 
alone  and  terminal  emulation  purposes  equally 
well . 


Smart  Terminals 

An  alternative  to  the  use  of  a  dumb 
terminal  in  a  secure  computer  system  is  to 
employ  a  trusted  smart  terminal  device.  This 
is  a  very  favorable  alternative  in  many  c.tses 
because  of  the  great  functional  enhancements 
which  many  smart  terminals  incorporate.  Some 
are  able  to  do  high  resolution  graphics,  while 
others  allow  great  ease  in  manipulation  of 
text,  several  pages  of  conversation  buffer, 
multiple  concurrent  terminal  sessions,  or  even 
multiple  sessions  on  different  machines  which 
are  physically  plugged  into  the  same  terminal. 
A  few  terminals  allow  all  of  these  things  and 
more.  Needless  to  say,  these  devices  can 
increase  the  productivity  of  the  mainframe 
user  .immensely,  while  presenting  the  use.r  with 
a  much  nicer  machine  interface.  Apparently, 
everyone  wins.  Unfortunately,  this  is  not 
true  from  the  viewpoint  of  someone  trying  to 
secure  a  system  which  uses  smart  terminals  for 
communication  with  a  mainframe. 

There  are  several  features  of  smart 
terminals  which  can  pose  major  threats  to 
security.  Foremost  among  these  are:  the 
threat  of  spoofing,  the  ability  to  relabel 
sensitive  data,  the  ability  to  open  extremely 
high-bandwidth  covert  channels,  and  the 
ability  of  such  a  terminal  to  interfere  with  a 
trusted  path.  Object  reuse  can  present  a 
readily  exploitable  threat.  Each  one  of  these 
flaws  could  be  used  to  compromise  sensitive 
data  across  all  levels  of  the  trusted 
computing  base  (TCB)  . 

The  spoofing  attack  could  be  employed  by 
writing  a  program  which  runs  on  the  smart 
terminal  device.  This  program  simulates  a 
successful  connection  to  the  host  machine  and 
a  logon  banner.  The  program  then  prompts  the 
user  for  their  password,  and  stores  the 
password  for  later  retrieval  by  some  malicious 
user.  The  attack  is  identical  to  the 
classical  spoofing  attack,  but  is  carried  out 
by  the  terminal  rather  than  the  host.  This 
can  make  it  more  difficult  to  locate  the 
perpetrator.  This  problem  goes  hand  in  hand 
with  the  problem  of  trusted  path,  which  is  not 
addressed  by  the  Department  of  Defense  Trusted 
Computer  System  Evaluation  Criteria  (TCSEC) 
until  the  B2  level.  Once  one  has  a  trusted 
path,  a  spoofing  attack  from  the  terminal 
level  is  no  longer  a  problem;  however,  in  a 
smart  terminal  which  features  user- 
programmable  keys,  the  "secure  attention"  key 
may  be  reprogrammed  by  a  malicious  user  to 
destroy  trusted  path  and  allow  a  spoofing 
attack  to  take  place.  Thus,  the  secure  smart 
terminal  must  have  at  least  one  key  —  the 
"secure  attention"  key  -  which  CANNOT  be 
reprogrammed.  This  key  should  send  some 
unchangeable  signal  to  the  host,  which  the 
host  must  interpret  as  a  request  for  trusted 
path  establishment.  In  addition,  the  terminal 
must  have  no  way  of  generating  that  signal 
except  via  the  "secure  attention"  key. 

A  smart  terminal  may  also  have  some 
"conversation  buffer;"  that  is,  some  memory  of 
the  tr.  usactions  between  the  user  and  the 
host.  In  many  systems,  everything  the  user 
inputs  and  everything  the  host  machine  outputs 
is  saved,  up  to  the  limits  of  memory  included 
in  the  terminal.  In  this  conversation  buffer 
there  is  great  potential  for  subversion  of 


data.  The  user  password  may  be  saved  in 
plaintext,  or  any  sensitive  information  which 
the  user  may  have  been  working  with  may  be 
able  to  be  recalled  ny  the  touch  of  a  single 
button.  This  can  be  a  great  convenience  and 
enormous  time-saver  to  the  legitimate  user, 
but  if  that  user  logs  off  and  leaves  his  or 
her  terminal  without  clearing  the  terminal's 
memory  then  the  oroblem  of  object  reuse 
occurs.  The  object  is,  in  this  case,  the 
terminal's  memory;  this  memory  must  be  cleared 
between  users,  so  that  there  is  no  possibility 
that  one  user  can  get  at  another  user's  data. 
The  clearing  of  memory  must  therefore  take 
place  after  the  termination  of  each  terminal 
session,  as  well  as  any  other  time  where 
failure  to  do  so  could  violate  system  security 
policy,  such  as  downward  level  changes. 

Since  any  smart  terminal  must  have  some 
ability  to  locally  process  data,  another 
attack  may  be  effected.  This  one  is 
substantially  more  difficult  and  intricate 
than  those  mentioned  thus  far,  but  is 
certainly  as  compromising.  If  the  terminal 
software  in  a  smart  terminal  is  modified  by  a 
malicious  user,  the  terminal  could  be  usee,  to 
relabel  sensitive  data  by  intercepting  and 
modifying  input  lines  according  to  its 
programming,  allowing  it  to  downgrade  or 
otherwise  compromise  sensitive  data.  This  is 
a  classic  example  of  a  "Trojan  Horse"  attack, 
applied  through  the  use  of  a  terminal. 

The  final  method  of  attack  which  will  be 
detailed  here  applies  only  to  a  terminal  which 
supports  multiple  concurrent  terminal 
sessions,  either  on  one  host  or  across  many 
hosts.  This  is  the  problem  of  covert 
channels.  Covert  channels  have  long  been 
recognized  as  a  means  of  downgrading  sensitive 
data  on  a  host  system,  and  could  be  used  to 
downgrade  information  on  a  terminal  as  well. 
On  a  mainframe,  the  covert  channel  is  often 
i slated  to  monitoring  of  use  of  system 
resources.  In  a  smart  terminal,  a  covert 
channel  could  take  the  form,  for  example,  of 
the  use  of  ACK  and  NACI<  signals  between  the 
terminal  and  the  host,  each  signaling  to 
another  concurrent  process  either  a  one  or 
zero  bit  of  information.  This  is  a  simple 
operation,  but  an  effective  one  nonetheless. 

Regardless  of  all  of  the  possible  attacks 
which  might  be  made  on  a  computer  system 
through  the  use  of  a  smart  terminal,  the  risks 
arc  not  insurmountable.  All  of  the  above 
security  weaknesses  which  smart  terminals  may- 
exploit  can  be  done  away  with  in  properly 
designed  and  installed  smart  terminal  devices. 


The  major  problem  revolves  around  trusted 
path.  If  the  user  can  be  assured  that  he  or 
she  is  in  contact  with  trusted  software  at 
both  the  host  and  the  terminal,  many  of  the 
opportunities  for  defeating  the  security  of 
the  terminal  can  be  removed.  All  trusted  path 
mechanisms  require  the  physical  integrity  of 
all  devices  which  are  part  of  the  trusted 
path.  This  is  readily  accomplished  at  the 
mainframe  leve] ,  but  can  be  difficult  to 
assure  at  each  terminal,  particularly  when 
terminals  are  distributed  throughout  a 
complex.  One  method  is  to  seal  shut  the 
casing  of  the  terminal  with  some  protective 
and  unforgeable  seal;  this  seal  would  show  any 
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sign  of  tampering,  and  users  would  be 
instructed  not  to  use  any  terminal  which  had 
been  tampered  with,  and  report  it  immediately. 
Physically  locking  down  the  terminal  in  a 
manner  in  wnich  it  could  not  be  easily 
tampered  with  is  another  solution.  One  major 
objective  of  either  of  these  methods  is  to 
insure  the  integrity  of  the  secure  attention 
key,  which  would  generate  a  non-maskable 
interrupt  to  both  the  host  and  the  smart 
terminal,  and  guarantee  to  the  user  that  the 
software  at  both  ends  of  his  or  her  connection 
was  trusted.  The  other  major  objective  of 
physical  protection  of  the  terminal  device  is 
to  insure  the  integrity  of  the  terminal's 
trusted  software.  This  software  is  often  ROM- 
resident,  and  with  the  replacement  of  a  single 
chip,  a  malicious  user  could  compromise  the 
entire  system. 

One  example  of  a  way  to  cut  down  on  the 
amount  of  trust  placed  in  a  ROM-based  terminal 
program  in  the  smart  terminal  is  to  cause  the 
terminal  proqram  to  be  downloaded  from  the 
host  when  the  user  hits  the  secure  attention 
key.  Assuming  the  integrity  of  the  secure 
attention  key,  this  provides  the  user  with 
good  assurance  that  he  is  using  trusted 
software;  it  also  allows  upgrades  to  be  made 
to  the  terminal  program  very  easily,  and  much 
less  expensively  than  replacing  the  ROMs  in 
every  smart  terminal  at  the  installation. 

The  problem  of  object  reuse  in  a  smart 
terminal  can  be  partially  solved  by  erasing 
the  conversation  buffer  as  soon  as  the 
connection  to  the  host  computer  is  terminated. 
This  may  be  accomplished  by  instructing  the 
hardware  or  the  firmware  in  the  smart  terminal 
that  the  conversation  buffer  is  to  be  emptied, 
say,  every  10  seconds  if  the  terminal  is  not 
connected  to  a  host.  The  terminal  may  also  be 
programmed  to  erase  the  conversation  buffer 
upon  receipt  of  a  given  signal  from  the  host. 
This  signal  would  then  be  sent  at  any  time  the 
conversation  buffer  should  be  cleared  (e.g. 
downward  level  changes) .  These  instructions 
should  be  encoded  in  hardware  or  firmware  so 
that  they  cannot  be  defeated  by  the  user 
reprogramming  the  smart  terminal  in  the  course 
of  his  or  her  terminal  session. 

Relabeling  of  sensitive  data  may  be  seen 
as  an  extension  of  the  trusted  path  problem. 
If  the  user  is  assured  that  he  or  she  is  using 
trusted  software,  then  relabeling  is  no  longer 
a  problem,  because  the  trusted  software  will 
not  allow  it.  Covert  '-hannels  also  become  no 
threat,  provided  that  the  trusted  software 
takes  measures  to  insure  that  they  are 
rendered  harmless.  what  is  crucial  is  that 
the  smart  terminal  software  be  trusted,  and 
that  the  user  be  able  to  confirm  that  he  or 
she  is  actually  using  the  trusted  software  at 
any  given  time. 

Since  the  major  threats  caused  by  the  use 
of  a  smart  terminal  have  been  addressed,  the 
question  becomes  one  cf  proving  that  a  given 
terminal  device  is  trustable.  In  the  case  of 
a  smart  terminal,  different  threats  can  >e 
mapped  to  different  levels  of  trust  in  the 
Department  of.  Defense,  Trusted  Computer,  System 
Evaluation  Criteria.  The  TCSF.C  does  not 
address  terminals  as  such;  but  by  mapping  the 
applicable  Criteria  requirements  to  terminal 
devices,  it  may  be  possible  at  some  point  in 


the  future  to  define  "levels  of  trust"  within 
the  realm  of  terminals  and  terminal  emulation 
programs.  One  could  then  speak  of  a  "B2- 
trustable"  terminal,  for  example.  Such  a 
terminal  would  meet  B2-level  requirements  for 
all  relevant  features,  among  which  would  be 
object  reuse,  covert  channels,  mandatory  flow 
policies,  and  trusted  path.  A  B2-trustable 
terminal  would  also  require  such  things  as  B2- 
level  configuration  management  and  design 
documentation.  It  would,  however,  omit 
requirements  which  do  not  apply  to  a  terminal 
device,  such  as  discretionary  access  controls 
and  auditing.  A  terminal  of  this  sort  could 
be  used  to  run  concurrent  sessions  at  multiple 
levels  (say.  Secret  and  Top  Secret)  and  be 
trusted  to  enforce  the  mandatory  flow  policies 
of  the  system,  depending  upon  the  level  of 
trust  bestowed  upon  the  terminal. 

If  this  methodology  were  to  be  uniformly 
applied,  it  could  be  said  that  a  C2-level 
smart  terminal  -  one  which  handled  object 
reuse  and  some  spoofing  problems  -  could  be 
connected  to  any  C2  system  which  could  be 
adapted  to  handle  its  special  protocols,  etc. 
without  placing  the  system  in  grave  danger  of 
compromise.  The  same  could  be  said  of  systems 
at  any  level  of  the  Criteria;  if  we  have  a  B2- 
level  terminal  device,  then  it  should  be 
trusted  enough  that  we  can  connect  it  to  not 
just  one  but  two  or  more  B2-level  hosts  which 
fall  within  the  same  range  of  trust,  and  rely 
on  our  terminal  device  to  maintain  the 
integrity  of  data  labels.  This  involves 
placing  a  great  deal  of  trust  in  terminal 
devices.  To  this  point,  the  NCSC  has  not 
evaluated  them;  however,  this  will  have  to 
change  if  the  NCSC  wishes  to  provide  its 
clientele  with  an  Evaluated  Products  List 
( EPL)  full  of  modern  and  user-friendly 
equipment . 


Secure  Workstations  as  Smart  Terminals 

Perhaps  the  optimal  solution  to  the  need 
for  secure  smart  terminals  may  be  solved  by 
the  use  of  the  forthcoming  secure  workstation 
as  a  smart  terminal.  This  gives  the  user  the 
best  of  both  worlds;  the  power  of  a  mainframe 
when  needed,  with  the  convenience  of  smart 
terminal  features,  and  the  ability  to  do 
stand-alone  processing  for  those  jobs  where  a 
secure  microcomputer  workstation  will  suffice. 
A  configuration  such  as  this  also  makes 
possible  many  useful  and  security-relevant 
events  which  require  some  analysis. 

To  begin  with,  in  order  to  rely  on  and 
trust  the  terminal  software  of  the  secure 
workstat i on ,  we  must  include  it  in  the  Trusted 
Computing  Base  (TCB)  of  the  workstation.  This 
will  allow  the  terminal  software  to  be  trusted 
at  the  same  level  as  the  workstation,  That 
is,  a  B2-levei  workstation  may  possess  up  to 
132-level  smart  terminal  trustabil ity ;  it  could 
tnerefore  be  used  as  one  would  use  a  B2~level 
smart  terminal.  In  addition,  when  r.ot  in  use 
as  a  terminal,  it  would  retain  the 
functionality  of  a  secure  workstation,  within 
certain  limits. 

One  important  limit  would  be  caused  by  the 
range  of  trust  which  is  given  to  trusted 
computer  systems  In  the  example  given  above 
of  a  32-levol  trusted  workstation,  the 


Bibiliography 


terminal  software  could  be  trusted  up  to  a  B2 
level.  Thus,  the  secure  smart 
terminal/workstation  as  a  whole  would  have  a 
range  of  trust  identical  to  a  B2  system.  If 
the  machine  were  connected  to  a  host  (or 
hosts)  which  contained  Confidential  and  Secret 
information,  and  the  workstation  was  used  to 
process  Unclassified  and  Confidential 
information  locally,  the  range  of  information 
accessible  by  that  machine  would  span  the 
range  of  Unclassified-Secret.  That  range  is 
too  great  to  be  entrusted  to  a  B2-level 
trusted  system,  according  to  the  Computer 
Security  Requirements  document.  Care  must  be 
taken  that  systems  of  this  type  are  not 
inadvertently  trusted  beyond  what  can 
reasonably  be  expected  from  them. 

It  is  also  important  to  realize  that  a 
host  cannot  be  considered  secure  at  a  level 
higher  than  that  of  its  lowest  terminal  or 
workstation,  unless  the  entire  configuration 
has  been  specifically  evaluated  and  it  has 
been  shown  that  that  is  the  case.  A  B3-level 
trusted  host  may  be  subverted  through  use  of 
covert  timing  channels  on  a  B2-level  trusted 
workstation,  for  example.  Basically,  all  of 
the  security  problems  which  may  plague  a  smart 
terminal  exist  for  a  secure  workstation 
running  smart  terminal  emulation  software. 
Any  further  problems  relate  to  che  addition  of 
some  form  of  permanent  storage  in  the  secure 
workstation.  If  the  smart  terminal  emulator 
takes  advantage  of  the  abundance  of  storage 
(typically  several  megabytes  of  hard  disk)  to 
provide  additional  features  for  the  uploading 
and  downloading  of  data,  extreme  care  must  be 
taken  that  the  security  policies  of  the  system 
cannot  be  violated  through  its  use.  Again, 
the  trusted  terminal  software  will  have  to  be 
evaluated  by  the  NCSC  along  with  the  rest  of 
the  workstation  in  order  to  provide  assurance 
that  the  security  of  the  system  will  not  be 
compromised. 


Conclusion 

It  is  obvious  that  a  smart  terminal  can 
greatly  increase  the  productivity  of  the 
typical  mainframe  user.  It  is  also  obvious 
that  a  smart  terminal  can  significantly 
jeopardize  the  security  of  its  host  machine 
through  many  and  varied  mechanisms.  However, 
these  risks  can  and  should  be  overcome  if  the 
user  community  is  to  be  expected  to  switch 
over  to  using  secure  computer  systems.  If 
presented  with  an  ergonomic:  and  pleasant  user 
interface,  the  user  will  not  have  to  sacrifice 
efficiency  and  ease  of  use  in  order  to  use  a 
secure  system  rather  than  a  non-secure  system. 
This  should  increase  user  acceptance  of  secure 
computer  systems  dramatically.  Since  it  is 
imperative  that  both  government  and  industry 
implement  the  use  of  secure  computer  systems, 
it  is  only  logical  that  a  comfortable  user 
interface  be  provided.  The  use  of  smart 
terminals  in  secure  computer  systems  can 
provide  this  interface,  and  perhaps  encourage 
m  my  hesitant  prospective  users  to  "go 
secure . 11 
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ABSTFACT 

There  is  much  debate  in  the  computer  security  community  as  to 
whether  or  not  the  Department  of  Defense  Trusted  Computer  Systems 
Evaluation  Criteria  (the  Criteria)  can  be  applit  ■  to  database 
management  systems.  In  this  paper  we  will  examine  the  basic  control 
objectives  of  the  Criteria  and  the  fundamental  security  concerns  of 
database  management  systems,  we  will  compare  the  two  and  show  that, 
while  the  control  objectives  of  the  Criteria  are  applicable  to 
database  management  systems,  they  do  not  encompass  all  of  the  security 
concerns  in  database  management. 

The  views  and  opinions  expressed  in  this  paper  are  those  of  the 
authors  and  do  not  necessarily  reflect  official  National  Computer 
Security  Center  positions. 


INTRODUCTION 

The  need  for  secure  database  management 
systems  stems  from  the  fact  that,  within  the 
Department  of  Defense  (DoD)  and  in 
corporations  around  the  world,  there  is  an 
increasing  amount  of  information  being 
manipulated  through  database  management 
systems.  The  databases  usually  contain  some 
classified  or  otherwise  sensitive 
information,  forcing  these  systems  to  operate 
in  a  system-high  or  dedicated  mode.  A  user 
may  need  to  access  data  of  differing 
classification  levals  at  the  same  time: 
consequently,  data  must  be  duplicated  on 
separate  machines  for  different  se'trity 
levels  and  compart'.mants.  This  duplication  o; 
data  on  separate  machines  causes 
inconsistencies  ir  the  data.  There  is  an 
urgent  need  within  the  DoD  to  replice  these 
systems  with  multilevel  secure  sys:ems. 
Additionally,  other  commercial  customers  such 
as  financial  institutions,  would  also  be  able 
to  take  advantage  of  the  protection  these 
systems  can  offer. 

Computer  security  research  and 
development  began  in  the  late  1960's.  The 
earliest  work  concentrated  on  the  area  of 
multilevel  secure  operating  systems  with 
database  management  security  research  and 
development  receiving  relatively  little 
attention.  One  cf  the  main  reasons  for  this 
lack  of  attention  was  the  perception  that  one 
could  not  credibly  implement  a  secure 
database  management  system  which  v as 
dependent  on  the  security  controls  of  an 
untrusted  operating  system.  At  that  time, 
secure  operating  systems  we re,  for  the  most 
part,  nonexistent  .  r.inco  then,  a  few 
multilevel  secure  operating  syr.cems  have  been 
developed  by  commercial  vendors;  however,  a 
secure  multilevel  database  management  system 


su’ll  does  not  exist.  Present  day  database 
management  systems  do  not  provide  adequate 
security  controls  and  mechanisms  to  ensure 
that  users  are  allowed  to  access  only  that 
data  for  which  they  have  been  granted  a 
clearance  and  have  a  specific  "need  to  know." 

A  major  conclusion  of  a  1982  Summer  Study 
on  "Multilevel  Data  Management  Security"'*-  was 
that  computer  security  technology  had 
advanced  to  the  point  where  certifiable 
multilevel  database  management  systems  could 
be  built  for  several  specific  applications  in 
three  to  five  years.  However,  there  is  no 
metric  to  evaluate  "secure"  database 
management  systems  against.  It  has  been 
proposed  that  the  DoD  Trusted  Computer 
5  tQ.ms_Eya.lu  a  t_ion_Cr  i  ter_i  a  -  (the  Criteria) 
is  sufficient  as  a  database  manaoement  system 
security  criteria.  We  do  not  subscribe  to 
this  view. 

In  this  paper  we  will  examine  the  basic 
objectives  and  requirements  of  the  Criteria 
to  discover  where  they  may  fall  short  of  the 
requirements  for  security  in  a  database 
management  system.  The  views  expressed  in 
this  paper  are  those  of  the  authors  and  are 
not  intended  to  be  taken  as  policy.  This 
paper  is  an  attempt  to  raise  the  readers 
awareness  of  the  issues  vital  to  database 
security  that  have  not  been  adequately 
addressed. 


CRITERIA 

We  begin  by  pointing  out  that,  when  the 
Criteria  was  published  in  1983,  it  was 
defined  to  apply'  to  both  trusted  general- 
purpose  and  trusted  embedded  systems,  not  for 
direct  application  to  database  management 
.systems.  With  that  fact  in  mind,  the 
Criteria  was  developed  for  a  number  of 
reasons : 


°  To  provide  users  with  a  metric  with 
which  to  evaluate  the  degree  of  trust  that 
can  be  placed  in  computer  systems  for  the 
secure  processing  of  classified  and  other 
sensitive  information, 

°  To  provide  guidance  to  manufacturers 
as  to  what  security  features  to  build  into 
their  new  and  planned,  commercial  products  in 
order  to  provide  widely  available  systems 
that  satisfy  trust  requirements  for  sensitive 
applications. 

°  To  provide  a  basis  for  specifying 
security  requirements  in  acquisition 
specifications . 

In  order  to  meet  these  goals,  the 
Criteria  sets  forth  three  basic  control 
objectives  which  are  concerned  with  security 
policy,  accountability,  and  assurance. 

The  first  of  these,  the  security  policy 
control  objective,  requires  that  a  statement 
of  intent  with  regard  to  control  over  access 
to,  and  dissemination  of  information  must  be 
precisely  defined  and  implemented  for  each 
system  that  is  used  to  process  sensitive 
information.  The  security  policy  must 
accurately  reflect  the  laws,  regulations,  and 
general  policies  from  which  it  is  derived. 

In  systems  processing  classified  or 
other  specifically  categorized  sensitive 
information,  provisions  must  be  included  for 
the  enforcement  of  mandatory  access  control 
rules.  These  provisions  must  include  a  set 
of  rules  for  controlling  access  based 
directly  on  the  comparison  of  an  individual's 
clearance  or  authorization  for  the 
information  and  the  classification  or 
sensitivity  designation  of  the  information 
being  sought.  These  rules  should  also 
control  access  based  indirectly  on 
considerations  of  physical  and  other 
environmental  factors  of  control. 

Systems  designed  to  enforce  a  mandatory 
security  policy  must  store  and  preserve  the 
integrity  of  classification  or  other 
sensitivity  labels  for  all  information. 

Labels  exported  from  the  system  must  be 
accurate  representations  of  the  corresponding 
internal  sensitivity  labels. 

These  systems  must  also  include 
provisions  for  the  enforcement  of 
discretionary  access  control  rules.  That  is, 
they  must  include  a  consistent,  set  of  rules 
for  controlling  and  limiting  access  based  on 
identified  individuals  who  have  been 
determined  to  have  a  need-to-know  for  the 
information. 

The  accountability  control  objective 
requires  that  systems  processing  or  handling 
classified  or  other  sensitive  information 
must  assure  individual  accountability 
whenever  either  mandatory  or  discretionary 
security  policies  are  invoked.  Futhermore, 
to  assure  accountability  the  capability  must 
exist  for  an  authorized  and  competent  agent 
to  access  and  evaluate  accountability 
information  by  a  secure  means,  within  a 
reasonable  amount  of  time  and  without  undue 
difficulty. 


The  assurance  control  objective  requires 
that  systems  processing  or  handling 
classified  or  other  sensitive  information 
must  be  designed  to  guarantee  correct  and 
accurate  interpretation  of  the  security 
policy  and  must  not  distort  the  intent  of 
that  policy.  Assurance  must  be  provided  that 
correct  implementation  and  operation  of  the 
policy  exists  throughout  the  system's  life- 
cycle. 

We  believe  that,  for  the  most  part, 
these  control  objectives  have  a  great  deal  of 
merit  when  put  in  the  context  of  database 
systems.  However,  they  are  not  quite  enough 
to  cover  all  of  the  concerns  that  are  faced 
when  attempting  to  develop  a  secure  database 
management  system.  We  must  consider  data 
integrity,  inference,  aggregation,  and  many 
other  problems  not  addressed  in  the  Criteria. 
We  must  also  expand  on  the  concepts  of 
labeling  and  auditing  when  dealing  with 
database  systems. 

EXAMPLE 

In  order  to  make  the  security  concerns 
associated  with  securing  a  database 
management  system  more  evident,  we  will  use 
the  sample  database  shown  in  Figure  1  to 
provide  examples  of  the  issues  discussed 
below.  The  sample  database  will  cor.-  .1-  of 
personnel  information.  The  databtv  •.  ird 
will  contain  the  employee's  name,  .  j. 

security  number  (ssn) ,  sex,  salary,  jt 
department. 

NAMF  SSN  SEX  SALARY  DEPT 


John 

- f-— 

| 123456789 | 

M 

-  +  - 

1 

50000 | 

A 

Ronda 

|268034721| 

F 

.  |  - 

1 

25000 | 

B 

Brian 

I  106638528  1 

M 

1 

17000| 

C 

Larry 

| 186539679| 

M 

1 

35000 | 

A 

Bruce 

| 873595357 | 
_+ - +  . 

M 

-+- 

44900 | 

B 

FIGURE  1. 


DATA  ' NTEGRITY 

In  the  Criteria's  control  objectives, 
integrity  is  only  discussed  as  it  relates  to 
sensitivity  labels  and  system  integrity.  For 
database  managemant  systems,  we  must  extend 
the  notion  of  integrity  to  address  the  issues 
of  accidental  or  unauthorized  modification  of 
data  and  integrity  checking  for  the  accuracy 
or  correctness  of  data  within  the  database. 
The  first  integrity  issue  is  that  some  system 
data  may  need  to  be  viewable  by  all  security 
levels  but  only  modifiable  by  certain  trusted 
programs  or  authorized  users^ .  This  is 
exemplified  by  the  case  of  a  user  examining 
the  sample  database  for  the  first  time  and 
wanting  to  view  the  structure  of  the  record 
in  the  system  catalog.  We  want  him  to  have 
access  for  examining  the  structure  of  this 
table  but  not  access  for  modifying  it.  We 
would  want  this  access  to  be  regulated 
through  a  mandatory  policy.  The  mandatory 
policy  of  the  Criteria  only  addresses  the 
improper  disclosure  of  information,  not  its 
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modification.  An  integrity  policy 
requirement  is  needed  to  enforce  the 
prevention  of  unauthorized  or  unintentional 
modification  or  destruction  of  data  or  other 
essential ,  database-related  information.  It 
must  be  precisely  defined  and  implemented  for 
each  system  processing  sensitive  information 
and  must  work  in  concert  with  the  system 
security  mechanisms  and  controls. 

In  order  to  ensure  that  the  data  in  our 
database  remains  correct  "integrity 
constraints"  must  be  imposed  on  individual 
transactions  being  performed  on  our  database. 
A  simple  example  of  an  integrity  constraint 
for  the  sample  database  in  figure  1  would  be 
that  all  sala '■  _  values  must  be  greater  than 
zero.  The  data  integrity  problem  is 
exemplified  in  the  above  database  when  a  user 
wishes  to  change  the  department  of  John  to  Z. 
Assuming  that  the  user  has  authorized 
discretionary  access  rights,  the  issue  to  be 
addressed  is  whether  or  not  the  value  to  be 
placed  in  the  field  is  an  acceptable  value. 

In  other  words,  does  a  Z  department  exist 
within  this  organization?  Another  problem 
that  can  arise  from  the  lack  of  data 
integrity  controls  is  that  a  user  ma'/  be  , r: : 
to  write  a  large  quantity  of  false  or 
incorrect  data  to  tne  above  database, 
rendering  any  queries  on  this  database 
useless.  Although  some  commercial  systems  do 
provide  some  integrity  checking,  most 
integrity  constraints  are  weak  or 
nonexistent4.  Most  integrity  checking  today 
is  still  done  by  user-written  procedural  code 
executed  outsido  the  control  of  the  database 
management  system. 

As  mentioned  by  Date,  many  systems 
claiming  to  provide  data  integrity  are 
ictually  using  the  term  to  mean  concurrency 
control.  Systems  that  provide  "integrity"  in 
this  sense  typically  guarantee  only  that 
interference  between  two  concurrently 
executing  transactions  cannot  occur;  they  do 
not  concern  themselves  with  the  question  of 
whether  individual  transactions  are  correct 
in  themselves. 

Under  the  Criteria's  extension  of  the 
assurance  control  objective,  there  is  a 
requirement  for  "System  Integrity."  The 
system  integrity  requirement  states  that: 
"hardware  and/or  software  features  shall  be 
provided  that  car.  be  used  to  periodically 
validate  the  correct  operation  of  the  on-site 
hardware  and  firmware  elements  of  the  Trusted 
Computing  Base  (TCB; ."  Does  this  requirement 
have  any  application  in  the  database 
management  system  world,  or  is  it  sufficient 
to  rely  on  che  operating  system  to  handle 
system  integrity?  Does  this  requirement 
apply  to  software  releases  of  database 
management  systems,  cr  only  hardware 
modi f ication? 

INFERENCE 

The  inference  problem  is  de  > ned  as  the 
compromise  or  increased  probability  of 
compromise  by  deduction  of  unauthorized 
information  due  to  combinations  of  the 
possession,  known  existence,  known  absence, 
chronology,  and  location  of  authorized 
information.  It  may  be  considered  a  covert- 
channel  of  database  management  systems.  It 
is  a  serious  problem  that  must  be  reconciled 
before  a  database  management  system  can  be 


regarded  as  secure.  As  an  example  of  the 
inference  problem,  consider  the  following:  if 
the  quantity  (q)  of  some  manufactured  item  jj 
classified,  then  either  the  to.al  production 
budget  (b;  or  the  cost  per  item  (c)  must  be 
classified,  since  quantity  (q)  cou1 d  be 
derived  as  q  =  b/c. 

There  are  many  unanswered  questions  in 
the  area  of  inference  control.  For  instance, 
can  the  problem  be  addressed  or  quantified  in 
a  genera]  way,  or  must  it  be  addressed  case 
by  case  for  each  site  processing  ser^iaive 
data  or  each  specific  application?  Should 
metrics  be  developed  to  describe  and  quantify 
an  acceptable  level  of  inference  control? 
Should  we  require  that  abstract  tools  be 
provided  in  a  database  management  system  so 
that  inference  control  can  be  builtin  at  each 
site?  if  inference  is  actually  another 
covert  channel,  should  it  or  could  it  be 
audited  in  the  conventional  sense  of  the 
Cr  iteria? 

Since  it  is  unlikely  that  the  general 
algorithms  can  be  defined  for  limiting  the 
inference  problem,  we  believe  it  would  be 
wrong  to  require  that  a  complete  solution  to 
the  problem  be  built  into  a  database 
management  system.  However,  metrics  should 
be  developed  to  define  acceptable  bandwidths 
of  possible  inference  attacks,  and  mechanisms 
should  be  required  to  be  available  within  a 
system  which  will  allow  the  inference  problem 
to  be  restricted  to  an  acceptable  level. 

These  restrictions  could  then  be  implemented 
by  each  site  as  the  need  arose.  The  audit 
mechanism  must  also  be  able  to  audit  possible 
inference  attacks. 

AGGREGATION  and  CONTEXT 

The  classifications  assigned  to  data 
must  account  for  the  data's  associations  or 
relationships  with  other  data.  For  example, 

1  le  unclassified  data  describing  a  flight  may 
be  classified  when  the  flight  itself  becomes 
explicitly  associated  with  a  particular 
mission,  cargo,  or  passenger. 

Because  classification  can  increase  with 
context,  an  assemblage  of  data  items  may  have 
a  sensitivity  far  higher  than  that  of  an 
individual  item  in  the  assemblage.  For 
example,  the  location  of  one  particular 
submarine  is  likely  to  be  less  sensitive  than 
the  location  of  all  submarines.  Another 
example  is  that  a  single  phone  number  may  be 
less  sensitive  than  a  complete  telephone 
d i rectory . 

Since  classification  depends  on  context, 
it  is  not  enough  to  store  labels  with  the 
physical  data  records  in  the  database. 

Methods  are  also  needed  for  determining  :he 
classification  of  data  when  it  is  associated 
with  other  data  and  for  managing 
modifications  in  these  associations.  General 
algorithms  for  context  classification  and 
data  aggregation  may  only  be  possible  on  a 
per  application  basis,  it  may  not  be  possible 
to  maintain  these  relationships  on  a  general 
database  management  system  level.  However, 
mechanisms  can  and  should  be  provided  so  that 
labels  can  be  enforced  on  aggregated  data 
once  it  's  identified  in  a  particular 
&ppi  icat on  . 


LABELING 

Labeling  is  an  area  in  which  the 
Criteria  may  fall  short  of  as  well  as  exceed 
the  needs  of  database  systems.  It  falls 
short  in  that  there  are  no  requirements  for 
labeling  according  to  the  context  of  the 
data.  It  may  exceed  our  needs  in  that  a 
database  system  does  not  operate  devices  and, 
therefore,  should  be  able  to  rely  on  the 
operating  system  for  exportation  of  data  to 
the  proper  devices.  However,  if  the  database 
system  operates  on  data  objects  which  are 
smaller  than  those  which  the  operating  system 
works  on  (e.g.,  the  operating  system  may 
operate  on  a  file,  while  the  database 
management  system  operates  on  records  within 
a  file),  an  interface  must  be  defined  such 
that  the  lower  levels  of  labeling  can  be 
supported  and  employed. 

There  are  some  very  difficult  issues 
which  must  be  addressed  in  the  area  of 
labeling.  If  the  labels  are  to  be  maintained 
at  the  enticy  level,  is  the  data  then  labeled 
at  the  user's  current  security  level,  or  can 
labels  exist  at  the  discretion  of  the  user? 
How  do  we  keep  data  from  migrating  to  the 
user's  highest  classification  and,  thereby, 
having  data  which  is  over-classified?  How 
are  data  labels  maintained  during  rollback 
and  recovery?  How  are  labels  affected  by 
changes  made  to  the  uat.a? 

We  believe  that  mechanisms  should  be 
required  which  allow  data  to  be  labeled  to 
whatever  granularity  is  required  by  an 
application  and  that  the  mechanism  ensure  the 
integrity  of  these  labels.  We  also  feel  that 
mechanisms  should  be  required  which  allow 
proper  labeling  of  aggregated  data. 

AUDITING 

Under  the  accountability  control 
objective  of  the  Criteria  there  is  a 
requirement  that  "the  TCB  be  able  to  create, 
maintain,  and  protect  from  modification  or 
unauthorized  access  or  destruction  an  audit 
trail  of  accesses  to  the  objects  it 
protects."  Auditing  is,  of  course,  very 
important  in  database  management  systems;  the 
issue  is  wha  do  we  audit?  The  types  of 
events  that  .  nould  be  audited  are 
logon/ logoff ,  creation/deletion/modification 
of  objects,  access  to  objects,  and  actions 
taken  by  database  administrators  and  system 
security  officers.  This  list  is  open  to  any 
additions,  but  we  feel  that  this  is  the 
minimum  set  of  events  that  should  be  audited 
in  a  database  management  system.  For  each  of 
these  events  the  audit  record  should  identify 
the  date  and  time  of  the  event;  user;  type  of 
event;  success  or  failure  of  the  event;  the 
user's  security  level;  level  of  the  object 
accessed;  and,  where  applicable,  before  and 
after  image  of  the  object.  Since  the  objects 
of  the  database  management  system  can  be  at 
such  a  fine  granularity,  the  audit  trail 
could  become  quite  large  very  quickly  and, 
therefore,  quite  useless  without  very 
sophisticated  audit-reduction  tools.  It 
would  seem  reasonable  to  make  auditing 
possible  to  the  finest  granularity  level  of 
the  data  but  also  allow  the  individual  sites 
the  discretionary  control  to  audit  whatever 


level  of  granularity  would  be  most  useful  to 
them.  The  Criteria  also  requires  that  the 
"system  administrator  shall  be  able  to 
selectively  audit  the  actions  of  any  one  or 
more  users  based  on  individual  identity 
and/or  object  security  level."  This  is  a 
very  useful  mechanism  to  have  in  place. 
However,  in  a  database  management  system  it 
would  also  be  very  useful  to  be  able  to 
selectively  audit  the  actions  taken  on  ar.y 
object  based  on  the  operation  and/or  the 
user's  or  object's  security  level. 

CONCLUSION 

Because  there  is  a  great  need  for 
security  in  database  management  systems  and 
the  security  requirements  for  various  sites 
differ,  it  is  very  important  to  have  a  metric 
with  which  to  evaluate  the  degree  of  trust 
that  can  be  placed  in  database  management 
systems.  It  is  also  very  important  to 
provide  a  basis  for  specifying  those  security 
requirements  in  acquisition  specifications. 
However,  in  performing  these  evaluations,  or 
when  generating  system  requirements,  we  must 
consider  all  of  the  security  relevant  issues. 
Because  the  Criteria  was  originally  defined 
to  apply  to  trusted  general-purpose  and 
trusted  embedded  systems,  the  control 
objectives  of  the  Criteria  (while  valid  when 
applied  to  database  management  systems) ,  are 
not  quite  sufficient  to  encompass  all  of  the 
security  concerns  in  database  management 
system.  We  must  consider  the  problems  which 
have  been  discussed  in  this  paper  as  well  as 
any  other  yet-to-be-discovered  problems  in 
the  area  of  secure  database  management 
systems.  Only  after  these  issues  are 
discovered,  fully  understood,  and  dealt  with 
properly  can  database  management  systems  be 
considered  secure. 
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TOWARDS  PRACTICAL  MLS  DATABASE  MANAGEMENT  SYSTEMS 
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This  paper  explores  some  practical 
considerations  for  using  the  integrity  lock 
technology  to  provide  multilevel  secure 
(MLS)  database  management  systems.  A 
prototype  architecture  is  described  which 
minimizes  the  source  code  modifications 
necessary  to  retrofit  the  integrity  lock 
mechanism  into  an  existing  database 
management  system  (DBMS).  The  INGRES 
relational  DBMS  is  used  to  demonstrate  the 
architecture.  In  addition  to  securing 
user-defined  relations,  the  integrity  lock 
software  secures  the  INGRES  data  dictionary 
relations,  thereby  supporting  classification 
at  the  record,  (.elation,  view,  and  index 
levels . 

Funding  for  this  work  was  provided  by 
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INTRODUCTION 

The  integrity  lock  technology  has  been 
demonstrated  as  a  feasible  near-term 
solution  to  the  need  for  multilevel  secure 
database  management  systems  [1].  The  work 
described  in  this  paper  derives  from  a 
current  Air  Force  project  to  field  this 
technology  for  use  in  a  production 
environment.  The  questions  are  no  longer 
ones  of  feasibility,  but  rattier  questions  of 
a  more  practical  nature.  This  paper 
addresses  two  such  genera),  questions: 


1.  How  can  the  integrity  lock  be 
retrofit  into  a  commercial  off- 
the-shelf  (COTS)  DBMS  without 
impacting  DBMS  maintainability? 
Could  the  integrity  lock  technology 
be  used  even  if  machine-readable 
source  code  were  not  available,  or 
is  access  to  source  code  a 
prerequisite  for  the  use  of  the 
technology? 

2.  Can  the  integrity  lock  technology 
be  used  to  address  any  of  the 
database  inference  and  aggregation 
issues?  Can  database  views  be 
secured  with  the  integrity  lock 
technology?  How  might  secure  views 
be  implemented  and  used? 


These  two  questions  translate  into  the 
implementation  goals  for  the  INGRES 
prototype : 

1.  Implement  the  integrity  lock 
technology  with  minimal  changes  to 
DBMS  source  code. 

2.  Use  the  integrity  lock  filter  to 
secure  the  data  dictionary  and 
thereby  extend  the  scope  of  data 
protection  within  the  database  to 
include  relations  and  database 
views . 


INTEGRITY  LOCK  TECHNOLOGY 

The  integrity  lock  concept  is  described 
in  detail  in  references  [2]  and  [3). 
Basically,  each  record  (or  other  database 
object)  is  tagged  with  its  classification. 
Then  an  unforgeable  cryptographic  checksum 
for  the  entire  record  is  computed  and  stored 
in  the  database  with  the  record.  This 
effectively  "seals"  the  data,  and  any 
unauthorized  modifications  to  the  data  or 
its  security  tag  can  subsequently  be 
detected.  In  addition,  access  to  individual 
records  (or  other  objects)  can  be  restricted 
based  on  some  specific  security  policy.  To 
implement  the  integrity  lock  mechanism,  a 
trusted  filter  monitors  the  operations  of  an 
existing  unt rusted  database  management 
system. 


Secur ity  Architecture 

The  integrity  lock  architecture  divides 
the  DBMS  software  into  two  separate 
executable  components:  one  which  interacts 
wit-h  a  user  and  one  which  accesses  the 
database  files.  All  communication  between 
the  two  components  is  monitored  by  a  trusted 
software  component  which  is  independent  of 
the  DBMS  software.  The  implementation 
requires  three  separate  execution  domains: 
the  trusted  monitor  (FILTER),  the  portion  of 
the  DBMS  which  interacts  with  the  user 
(USER),  and  the  portion  which  accesses  the 
data  files  (FILE).  Figure  I  illustrates  the 
interactions  among  these  environments. 
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Figure  1.  Integrit-.y  Lock  Architecture 


The  operating  system  (or  Trusted 
Computing  Base  ( TCB ) )  within  which  these 
three  components  are  executing  must  enforce 
some  basic  security  requirements.  The 
security  characteristics  of  each  domain  are 
as  fol lows : 

FILE  The  FILE  component  executes  at 
the  security  c lass i C ica t i  >n  of 
the  database  files.  The  FILE 
is  the  only  executable  module 
which  has  any  access  to  the 
database  files.  It  is 
prohibited  from  accessing  any 
output  devices  or  files  at  a 
lower  security  classi  l icat ion 
(i.e.,  a  mandatory  sec-’rity 
policy  is  enforced  by  the 
TCB). 

USER  The  USER  executes  at  the 
security  clearance  of  the 
individual  using  the  database. 
The  USER  is  prohibited  from 
accessing  objects  at  a  higher 
security  classification  and 
from  accessing  any  outpu' 
devices  or  files  at  a  lower 
security  classification,  as 
specified  by  the  TCB's 
mandatory  security  policy. 

FILTER  The  FILTER  executes  a*:  t-he 

security  c Lass i f i cat  ion  of  the 
database  files.  However,  it 
is  pr i v i leged  to  initiate  the 
execution  of  thp  USER  (at  a 
potentially  lower  security 
classification)  and  to 
communicate  with  it.  •  also 
uses  operating  system  -rusted 
functions  to  determine  the 
relevant  security 
classifications  and  to  audit 
secu r  i  ty- re lated  activii  ies. 
The  TUB  has  sufficient 
mechanisms  to  assure  t  tat  the 
Fit, TER  software  is 
tamperproof . 


The  prototype  was  implemented  within 
the  context  of  the  INGRES  data  base 
management  system  and  the  UNIX*  operating 
system  (BSD  4.2).  The  design  makes  use  of 
several  UNIX  secur i ty- related  features. 
However,  since  current  implementations  of 
UNIX  are  vulnerable  in  a  number  of  areas 
[4],  the  implementation  is  not  intended  to 
be  secure  within  existing  UNTX  environm-'nts. 


Secur ity  Pol  icy 

The  security  policy  for  access  to  the 
information  in  the  database  is  enforced  by 
the  trusted  FILTER.  For  the  purposes  of  the 
prototype,  tuple  (or  record)  level 
classification  was  used  with  a  simple 
mandatory  security  policy  based  on  the  1982 
Air  Force  Summer  Study  [5].  The  following 
is  a  summary  of  the  policies  (SC  is  .ecurity 
classification,  SSO  is  a  function  which  is 
true  if  the  user  is  currently  a  System 
Security  Officer): 


READ  Record 


APPEND  Record 


SC(user)  dominates 
SC ( record ) 

if  SSO(user)  then 

prompt  for  SC( record) 
else  SC (record)  = 

SC ( use  r ) 


UPDATE  Record  SC(user)  dominates  old 
SC ( record ) 
if  SSO(user)  then 
prompt  for  new 
SC( record) 

else  new  SC( record)  - 
SC(user ) 

DELETE  Record  SC(user)  dominates 
SC ( record ) 


There  are  no  other  mandatory  :r 
discretionary  access  control  policies  for 
the  prototype.  INGRES  supports  some 
discretionary  controls  which  may  he  used  in 
addition  to  the  integrity  lock  mandatory 
controls.  Since  the  UNIX  environment  does 
not  support  security  clearances  for  users, 
for  this  implementation,  the  applicable 
clearance  is  read  from  a  ".secure"  file 
within  the  user's  home  directory. 


PROTOTYPE  ARCHITECTURE 

The  primary  goal  of  the  INGRES 
integrity  lock  prototype  was  to  implement 
the  integrity  lock  mechanism  without 
changing  substantial  amounts  of  source  code. 
To  achieve  this,  the  INGRES  object  libraries 
were  split  along  functional  boundaries  into 
two  separate  sets.  The  executable  modules 
were  then  re-linked  into  the  USER  and  FILE 
components  of  the  integrity  lock 
architecture.  This  section  describes  the 
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FILTER  interface  which  mediates  access 
between  the  two  sets  of  INGRES  functions  and 
provides  an  implementation  methodology  for 
developing  an  integrity  lock  version  of  a 
COTS  DBMS. 


INGRES  Funct ional  Inter  face 

The  INGRES  system  is  highly  modularized 
and  contains  a  set  of  functions  for  low- 
level  access  to  relations.  These  functions 
include  relation  open  and  close,  get/put 
tuple  functions,  and  supporting  buffer 
management  functions.  The  approach  taken 
for  the  prototype  was  to  use  this  relation 
access  interface  as  the  vehicle  for  the 
FILTER  to  mediate  access  to  the  database. 
Figure  2  represents  the  standard  INGRES 
get_tuple  function  as  it  would  be  invoked  by 
the  INGRES  query  processor. 


gct_tuple  (relation_de3c.  tup)e_i«i.  tuple! 

where  relation  dtst  the  relation  descriptor 
diploid-  identifies  a  tuple 

tuple  a  pointer  for  the  returned  tuple 
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Figure  3.  INGRES  Process  Architecture 


functions.  The  construction  process  was 
done  in  five  major  phases.  At  the 
conclusion  of  each  phase,  there  was  a 
working  version  of  the  implementation  up  to 
that  point.  This  technique  allowed  the 
problems  encountered  with  each  phase  to  be 
resolved  prior  to  the  introduction  of  more 
design  detail.  The  five  major  phases  were 
as  follows: 
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Figure  2.  INGRES  Function  Invocation 


For  use  with  the  integrity  lock  filter, 
the  get_Luple  function  (along  with  all  of 
the  relation-level  functions)  is  replaced  by 
a  substitute  function  which  extracts  the 
parameters  from  the  call,  inserts  them  into 
a  message  buffer,  and  communicates  the 
buffer  (via  UNIX  pipes;  to  the  FILTER.  The 
FILTER  has  an  opportunity  to  perform  any 
security  processing  before  conveying  the 
message  on  to  the  FILE  process.  The  actual 
INGRES  get  tuple  function  is  invoked  by  the 
FILE  process,  and  the  tuple  retrieved  is 
passed  back  to  the  FILTER.  Here  the  FILTER 
will  recalculate  the  checksum  and  enforce 
the  mandatory  security  policy  prior  to 
passing  the  tuple  back  to  the  USER  process. 
Finally,  the  USER  process  will  store  the 
tuple  into  the  location  designated  by  the 
original  get  tuple  function  invocation. 
Figure  3  illustrates  this  process  at  a 
conceptual  level. 


Ueve  lo_ume nt  Methodol  ogy 

’o;:  the  operational  version,  only  three 
INGRES  source  modules  (out  of  a  total  of 
lldol  were  modified.  In  addition,  only  2700 
lines  of  additional  C  code  (including  1000 
lines  of  trusted  code)  were  needed  to 
implement  the  basic  integrity  lock 


1.  Simple  Prototype 

Simple  versions  of  the  USER, 
FILTER,  and  FILE  processes  were 
developed.  These  processes 
interacted  to  read  and  write  lines 
of  a  standard  UNIX  data  file. 

During  this  phase,  the  details  of 
the  inter-process  communication 
were  worked  out  and  shown  to  be 
effective.  Most  of  the  issues 
which  relate  to  the  operating 
system  environment  were  dealt  with 
in  this  phase. 

2.  DBMS  Restructuring 

This  phase  was  spent 
researching  the  INGRES 
implementation,  and  dividing  it 
into  two  pieces.  Once  the 
restructuring  was  complete,  the 
INGRES  software  was  integrated  into 
the  simple  prototype  from  phase 
one.  Using  the  resulting 
implementation,  it  was  possible  to 
verify  that  the  correct  arguments 
were  being  passed  through  the 
FILTER.  The  result  of  this  phase 
was  a  working  DBMS  without  any 
security  features. 

3.  Security  Processing 

The  next  phase  was  coding  the 
security  related  functions  and 
integrating  them  with  the  results 
of  phase  two. 

4 .  UNIX  Access  Control 

The  fourth  phase  was  to 
develop  an  environment  in  which  the 
UNIX  access  control  features  could 
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be  used  to  restrict  the  various 
processes  to  access  only  the 
appropriate  tiles.  If  the  UNIX 
operating  system  were  robust  enough 
to  Lesist  security  penetrations, 
these  access  controls  could  provide 
a  basis  for  secure  MLS  databases. 

5.  Secure  Data  Dictionary 

The  final  phase  applied  the 
integrity  lock  technology  to  the 
INGRES  data  dictionary.  The 
results  of  this  stage  are  the  topic 
of  the  next  section. 


SECURE  DATA  DICTIONARY 


The  final  phase  of  the  development 
integrated  security  processing  for  the 
relations  which  make  up  tne  INGRES  data 
dictionary;  these  were  not  secured  initially 
in  order  to  simplify  the  implementation. 

There  are  six  relations  in  the  data 
dictionary ; 

relation  The  re .at  ion  relation 

contains  a  record  for 
each  relation  defined  in 
the  database. 

attribute  The  att  r  ibute  relation 

contains  a  record  for 
each  attribute  of  each 
relation. 

tree  The  t_ree  relation 

contains  parsed  query 
trees  which  define 
database  views . 

protect  The  protect  relation 

specifies  INGRES 
discretionary  access 
controls . 

index  The  index  relation 

contains  a  record  for 
each  index  which  has  been 
created . 

integrities  The  integrities  relation 
is  used  to  specify  any 
update  integrity 
constra ints . 

By  including  these  relations  within  the 
scope  of  the  security  processing,  the 
descriptive  elements  of  the  database  are 
tagged  with  a  security  level  as  they  are 
created.  In  other  words,  if  a  relation  is 
created  when  the  database  administrator 
(DBA),  or  other  authorized  user,  is 
processing  at  the  SECRET  ievel,  then  the 
data  dictionary  records  for  the  relation 
will  also  be  tagged  at  the  SECRET  level. 
Similarly,  views,  indexes,  and  other  system 
entities  acquire  mandatory  security  labels. 

The  primary  result,  ol  this  extension  is 
that  relations  acquire  a  security 
classification  independent  of  the  level  of 


the  records  within  the  relation.  However,  a 
user  must  have  a  clearance  for  the  relation 
level  in  order  to  access  any  records  within 
the  relation.  A  second  practical  result  is 
the  ability  to  associate  a  security  level 
with  the  definition  of  a  database  view. 


Classified  Views 


A  database  view  is  simply  a  definition 
of  a  subset  of  the  database,  usually 
specified  in  the  DBMS  query  language.  When 
a  user  query  refers  to  a  view,  rather  than  a 
relation,  the  result  of  the  query  is  limited 
to  those  records  within  the  view.  (With  the 
integrity  lock,  the  result  is  further 
limited  to  those  records  for  which  the  user 
has  an  appropriate  clearance.)  Views  are 
frequently  used  to  provide  discretionary 
access  controls,  based  on  the  content  of  the 
data  records.  I'or  instance,  a  sales  manager 
may  be  restricted  to  access  only  those  sales 
records  for  his/her  region.  There  are 
current  research  efforts  to  determine  how 
views  might  best  be  used  to  provide 
mandatory  access  controls  [6], 

By  providing  for  security  labels  for 
database  view  definitions,  it  is  possible  to 
limit  users  to  views  for  which  they  have  a 
clearance  in  addition  to  limiting  them  to 
individual  records  for  which  they  have  a 
clearance.  Figure  4  illustrates  how  a  join 
of  two  relations  can  be  defined  at  a  higher 
classification  than  the  individual 
relations.  (The  range  statement  in  the 
INGRES  QUEL  language  associates  a  query 
variable,  used  in  the  where  clause,  with  a 
relation  or  a  view;  it  is  similar  to  a  from 
clause  i n  SQL . ) 


In  a  SECRET  session: 

create  Arelation  (attrAl,  attrA2  ...  attrAn) 
create  Brelation  (attrBl,  attrB2  ...  attrBn) 

In  a  TOP  SECRET  session: 

range  of  A  is  Arelation 
range  of  B  is  Brelation 

define  view  ABview  (attribute  sub-list) 
where  A.attrA2  ■=  B.attrB5 


Figure  4.  Classified  View  Definition 


The  ABv i ew  is  a  join  of  the  information 
within  the  Ar  e lat ion  and  the  Bre  lat ion  .  The 
join  operation  is  based  on  the  values  found 
in  aJ:u:A2  and  att rBb  that  are  equaL  in  both 
relations.  The  use  of  the  view  ABview  is 
limited  to  those  users  with  a  TOP  SECRET 
clearance,  independent  ol  the  level  of  the 
records  within  the  view. 

User  Restr i ct ions 

The  use  of  classified  views  requires 
r  wo  restrictions  wit  tun  the  user 

env i ronment : 


1.  A  user  may  access  only  one  view 
within  any  query.  This  eliminates 
the  possibility  of  joining  views. 

if  users  were  allowed  to  join  views 
together,  additional  inferences 
would  be  possible. 

2.  Only  the  database  administrator  has 
direct  access  to  relations;  all 
other  users  must  access  the 
information  within  the  database 
only  through  pre-defined  views. 

The  database  administrator  defines 
those  views  by  direct  references  to 
the  underlying  relations.  The  full 
power  of  the  query  language  is 
therefore  available  only  to  the 
database  administrator. 

These  two  restrictions  constrain  the  use  of 
the  query  language  to  reduce  the  potential 
scope  of  inferences  which  can  be  made.  They 
restrict  users  to  only  those  specific  views 
authorized  by  the  database  administrator. 


Unresolved  Issues 

There  are  several  uses  of  views  which 
would  be  helpful  for  multilevel  secure 
databases,  but  which  are  not  supported  by 
this  concept  of  classified  views.  For 
instance,  aggregations  over  an  authorized 
view  cannot  be  further  restricted.  It  is 
not  possible  to  classify  the  sum  of  the 
values  of  a  particular  field  accessible  by 
the  view  higher  than  the  view  itseif. 
Similarly,  this  type  of  classified  view 
cannot  be  used  to  sanitize  information.  The 
data  within  the  view  is  tagged  with  its 
classification  and  will  not  be  visible  to 
any  less  cleared  user  even  within  the 
context  of  a  pre-defined  view. 

The  integrity  lock  technology  is 
vulnerable  to  sophisticated  Trojan  horses 
within  the  untrusted  DBMS  [7].  This 
vulnerability  remains  an  issue  and  the  use 
of  classified  views  introduces  an  additional 
Trojan  horse  threat.  While  the  integrity 
lock  assures  that  the  classification  of  the 
view  can  not  be  altered,  it  does  not 
automatically  prevent  the  view  definition 
(called  a  query  tree)  from  being  tampered 
with  during  the  query  processing.  The  query 
tree  is  a  fundamental  INGRES  data  structure 
and  is,  in  fact,  modified  significantly 
during  the  query  processing.  The  scope  of 
the  Trojan  horse  threat  could  be  limited  by 
placing  portions  of  the  query  tree  under  the 
control  of  a  trusted  component. 


CONCLUSIONS 

Overall,  1 ne  ;esults  of  this  effort 
have  met  the  initial  goals.  In  total, 
including  the  secure  data  dictionary,  six 
INGRES  modules  were  modified  and  recompiled. 
Two  of  these  recompilations  were  due  to 
mixed  functionality  within  the  original 
code.  Both  were  initialization  routines 
which  affected  several  different  functional 
areas;  the  modifications  removed  the  code 
not  related  to  tin*  functions  needed  witni.n 


the  particular  process.  The  third 
modification  was  to  support  index  relations. 
Here,  an  assumption  was  made  in  the  original 
code  that  the  "tid"  would  be  the  last 
attribute  in  each  tuple;  however,  with  the 
addition  of  the  security  attribute,  that  was 
no  longer  true.  One  modification  was  made 
to  support  the  creation  of  a  secured  data 
dictionary,  and  two  modifications  were 
needed  to  put  the  user  restrictions  in 
place.  All  other  functionality  was 
implemented  within  the  integrity  lock 
software  itself. 

The  use  of  the  integrity  lock 
technology  to  secure  the  data  dictionary 
extends  the  usefulness  of  the  integrity  lock 
approach  while  providing  a  necessary  feature 
for  any  practical  secure  DBMS.  The  ability 
to  classify  views  provides  a  foundation  upon 
which  to  build  a  base  of  experience  to 
determine  how  views  can  best  be  used  to 
address  mandatory  access  control  needs  in  a 
database  environment. 

It  is  hoped  that  the  techniques  and 
processes  developed  for  this  implementation 
will  be  helpful  in  future  work  with  the 
integrity  lock  mechanism  and  with  other 
efforts  to  develop  multilevel  secure 
database  management  systems. 
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INTRODUCTION 

\  \  ,  ustcd  eomputer  system  is  designed  to  be  'sc'-ure' 
with  respect  to  some  well-defined  seejrby  policy.  There  are 
two  major  classes  of  information  security  policy:  ( 1)  secrecy 
policies  v  h’rh  gtivc!”  the  disclosure  of  information  and  (2) 
integrity  policies,  which  govern  its  modification.  AUhough 
much  of  the  literature  on  computer  security  emphasizes 
secrecy,  for  many  ‘vstonis  integrity  is  of  equal  or  greater 
importance  The  DoD  Trusted  Computer  System  Evaluation 
Criteria*  is  careful  to  encompass  (although  not  require) 
security  policies  (hat  include  integrity.  A  trusted  computer 
system  is  designed  to  protect  ‘sensitive  information,'  which  is 
(h  lined  in  the  Criteria  as  inhumation  that  must  bo  protected 
from  “unauthorized  diselosmc,  alteration,  loss  or 
destruction." 

In  databases,  the  term  ‘integrity’  is  interpreted  broadly, 
as  illustrated  by  the  following  definition  taken  fiom  Date2: 

"The  term  integrity  is  used  in  database 
contexts  witl  the  meaning  o i  accuracy, 
correctness,  or  validity.  'Pile  problem  of 
intfgiitv  is  the  problem  of  ensuring  that  '.Im 
data  in  the  database  is  accurate  -  that  is,  the 
problem  of  guarding  the  database  against 
invalid  updates.  Invalid  updates  may  lie 
coined  bv  errors  in  data  entry,  by  mistakes  oti 
the  part  of  the  operator  or  the  application 
programmer,  by  system  failures,  even  by 
deliberate  falsification.  The  trust  of  these, 
however  is  not  so  much  a  matter  of  integrity  as 
it  is  of  security  ...  The  term  'integrity'  is  also 
very  commonly  used  to  refer  just  to  Hie  special 
situation  ...  in  which  it  is  possible  that  two 
eoncin  renilv  executing  transactions,  each 
correct  in  itself,  may  interbre  with  each  other 
in  such  a  manner  as  to  produce  incorrect 
results  " 

In  this  paper,  we  address  all  aspects  of  integrity  in  ilnt  all 
are  essential  to  the  operation  of  m  cure  database  systems 

Classes  of  Integrity  Policies 

There  nr"  two  distinguishable  ispecls  of  integrity 
policies:  whether  a  given  iiu'dife'  >i ion  of  information  is 
authorized.  and  whether  the  mo.  fieation  results  m 
informal  ion  1  hat  is  in  sonic  sense  consistent  oi  rorrrrt. 

Ant  lioii/al  ion  is  Mil-divided  into  two  categories'  (I) 


mandatory  integrity  authorization ,  which  is  based  on 
integrity  classifications,  reflecting  importance  of  data,  and 
clearances,  reflecting  user  trustworthiness,  and  (2) 
discretionary  integrity  authorization,  which  is  based  on 
users'  needs  to  modify  information.  Both  mandatory  and 
discretionary  integrity  controls  can  protect  data  from 
malicious  tampering  and  destruction  as  well  as  from 
accidental  modification  and  destruction  through  operator 
errors  (e  g.,  an  operator  may  inadvertently  attempt  to  delete 
the  wrong  relalion)  or  faulty  software. 

Consistency  is  subdivided  into  three  categories:  (I) 
database  integrity  rules,  which  define  correct  states  of  a 
database  in  terms  of  relationships  among  the  data,  (2) 
recovery  management,  which  returns  the  database  to  a 
ronsistent  state  after  failure,  and  (3)  concurrency  controls, 
which  ensure  that  concurrent  transactions  do  not  interfere, 
thereby  creating  inconsistent  states  of  the  database. 

We  shall  discuss  each  aspect  of  integrity  in  more  depth 
lifter  firs'  discussing  assurance  for  tlu-se  different  aspects. 

Assurance 

The  notion  of  a  security  perimeter  is  essential  to 
obtaining  assurance  that  a  security  policy  is  actually  enforced 
by  the  Trusted  Computing  Base  (TUB)  of  a  system.  As 
stated  in  the  Criteria  “the  bounds  of  llie  TC'B  equate  to  the 
‘security  perimeter'  "  and  “includes  all  those  portions  .. 
essential  to  the  support  of  the  policy."  That  is,  t no  security 
perimeter  is  with  respect  to  the  seeuuty  policy  being 
enforced.  Thus,  the  two  categories  of  policy  ,  viz.,  mandatory 
and  discretionary,  may  well  have  two  distinct  security 
peiimeters  This,  of  course,  oniy  applies  to  systems  of  Class 
lil  or  above,  because  (.'lass  C  systems  do  not  support  e 
mandatory  policy. 

The  mandatory  policy,  for  both  secrecy  and  integrity, 
can  he  enforced  with  a  very  high  negr  o  of  assurance  against 
eoii'-erted  attacks,  including  Ttojan  horses.  As  the  evaluation 
classes  move  from  Ill  to  1!2,  B3,  and  finally  A l,  the  primary 
distinctions  relate  lo  the  use  of  improved  architecture, 
specification,  verification,  and  testing  to  increase  the 
asMirasirf  in  (lie  mandatory  a'-eess  controls  enforced  by  the 
Tt  (’•.  It  is  expected  that  (he  higher  evaluation  classes  will  be 
used  protect  against  users  with  a  wider  range  of 
an'  horizal  ions. 


In  contrast.  because  of  thrir  richer  policies, 
discretionary  access  controls  have  inherent  limitations 
(known  as  the  safety  problem''  )  and  more  complex 
mechanisms  than  mandatory  controls.  This  is  especially  true 
(or  database  systems  that  protect  data  at  the  granularity  of 
individual  elements  and  have  powerful  access  mechanisms, 
such  as  views,  which  rely  on  much  of  the  database  system  for 
their  support.  Because  of  the  inherent  as  well  as 
technological  limitations,  little  meaningful  assurance  of 
discretionary  controls  can  he  obtained  beyond  that  of  Class 
C2;  in  particular,  one  cannot  obtain  high  assurance  against 
Trojan  horses.  Fortunately,  this  matches  well  the  real-world 
need  for  discretionary  controls  for  need-to-know  ami 
corresponding  integrity  enforcement.  Moreover,  because 
discretionary  controls  operate  within  the  confines  of 
mandatory  controls,  the  damage  that  can  result  from  their 
failure  is  limited. 

Because  of  the  sharp  distinction  in  the  possible 
assurance  Tor  mandatory  versus  discretionary  controls  in  a 
database  system,  the  following  discussion  presumes  that  there 
may  he  two  distinct  security  perimeters  for  systems  at  Class 
B'J  and  above:  an  inner  perimeter  (the  ‘reference  monitor  ) 
for  mandatory  controls  and  an  outer  perimeter  (or 
perimeters)  for  discretionary  and  consistency  controls.  The 
maximum  assurance  that  seems  required,  and  the  maximum 
pructkal,  fur  the  portion  of  the  TCB  outside  the  mandatory 
perimeter  appears  to  he  that  prescribed  for  Class  C2. 

.■Vs  discussed  later,  the  assurance  requirements  for  ('lass 
B2  and  above,  in  particular  the  need  lo  control  covert 
channels,  affects  the  meaning  of  consistency  and  the 
functionality  of  other  aspects  of  a  database  system.  However, 
having  separate  security  perimeters  makes  it  possible  to  more 
meaningfully  address  these  problems. 

AUTHORIZATION  INTKGRITY 

Mandatory  Integrity  Authorisation 

Mandatory  security  poliri  o  are  particularly  important 
because  tlu-y  Icm'uIx  glut), al  and  |  -rsistent  properties  that 
ate  required  for  aut hori/at inr.s  in  a  secure  system.  V. 
d'-fineil  m  the  Criteria  .  mandatory  policies  employ  a  reliable 
label  lo  reflect  tin  degree  of  |.re'"ctiim  required  for 
iufoi ana* urn  and  lo  reflect  the  authorization  of  a  subject  io 
access  information  When  considering  integrity,  these  labels 
refleet  w ha!  t  lm  (  i  iiern  refers  to  a.-,  the  ‘sensil  is  it  v 
designation  of  tiie  information.’  or  what  is  commonly  termed 
the  inlrt/rilij  urrejot  rlr/sji.  or  simply  itilrgrily  rhi:‘.-i  o!  the 
information  objeeis  Fliere  is  a  comparable  lab  -|  tlmi  reflects 
an  tndn  idnal’s  author,' ration  for  l.'ie  mfonnat ion:  the,  label 
is  assigned  to  corresponding  -uhjeris  The  primary  sy-Vuis 
of  inlet  "St  are  those  that  ran  be  repr-’si  nler'  by  a  Formal 
Security  * 1  ■  h  <  y  Model,  -is  defined  in  'bet  nieria.  For  Midi  a 
s\  -t  eni  it  is  -|t"W  n  r  hat  if  the  mil  -  a!  Si  ate  of  the  sysl  "in  |s 
,et am1  with  r'",b"el  to  til.-  poll.  y.  ilmn  i  ll  f"' ure  slates  of  the 

sy  -t  ''III  U  ill  be  se,  ure 

For  i iiandat or\  iirei  y  policies,  the  sr>  p  i  y  access 
classes  must  form  a  latino  The,  1  ■quireue  ni  may  be 
appropriate  f.,r  in.md.alori  inirgriiy  policies  as  wi  ll,  .although 
non I:  1 1  ice  nia  n oat •  u  v  i litegrily  |n lin  e's  hax  "  been  pri 'posed  * 


For  lattice-based  policies,  the  integrity  classes  could 
correspond  to  integrity  levels  (analogous  to  secrecy  levels 
such  as  Sl'X'RKT],  category  sets  of  disjoint  integrity 
compartments  (analogous  to  secrecy  compartments  such  as 
CRYPTO),  or  both 

Six  mandatory  security  policies  have  been  variously 
proposed  to  deal  with  integrity.  In  the  context  of  the  above 
concept  of  mandatory  policy,  each  of  these  is  examined  as  a 
possible  integrity  policy  for  databases: 

1.  Strict  integrity 

2.  Bow-water  mark 

3.  King  policy 

•i.  Multilevel  security  with  no  write-up 

r».  Program  integrity 

6.  Domains  and  types 

Fhe  first  three  policies  were  introduced  by  Blba'1  as 
possible  policies  for  multilevel-secure  systems. 

Strict  Integrity  Policy  I  bis  policy  is  an  exact  dual 
of  multilevel  secrecy  as  defined  in  the  Bell  and  BaPadula 
inodelr>.  Bach  subject  and  object  is  assigned  a  fixed  integrity 
class  taken  from  the  lattice  of  integrity  classes,  nnd  strict 
integrity  is  preserved  by  prohibiting  a  subject  from  reading 
down  or  writing  up  in  integrity. 

There  are  two  distinct  considerations  in  assigning 
integrity  classes  to  objects  and  subjects.  First,  the  integrity 
class  of  the  object  to  be  protected  from  unauthorized 
modification  must  reflect  the  sensitivity  of  the  information, 
viz  tiie  potential  damage  that  could  result.  Second,  the 
integrity  class  of  I  he  subject  must  reflect  its  trustworthiness 
for  making  modifications.  However,  it  is  essential  to  note 
that  the  modifications  by  a  subject  are  effected  by  tiie 
programs  it  executes  and  the  data  that  control  the  execution 
of  these  programs.  Thus,  if  a  high  integrity  class  is  assigned 
to  objects  (files  or  segment.-)  containing  programs  nnd 
program  data,  tins  assignment  must  reflect  a  determination 
tliat  tin-  resulting  "Xeeut ioa  will  produce  only  acceptable 
modifient  i.ms, 

Tiie  strict  integrity  model  was  initially  introduced  to 
•  lea!  with  the  threat  of  deliberate  falsification  or 
contamination  of  very  sensitive  information.  One  such 
application  in  which  high  integrity  is  of  great  importance  is 
the  preparation  of  taigeting  data  that,  are  used  to  control 
ballistic  mi'siles.  The  practical  threat  is  not  so  much  (hat  an 
unauthorized  individual  will  be  allowed  to  use  such  a  system, 
but  rather  that,  a  program  and/or  data  maliciously  prepared 
will  be  inoorporatid  into  a  Trojan  horse  to  retarget  the 
weapons  towards  inconsequential  or  even  friendly  targets. 

Fins  kind  of  Trojan  horse  could  be  implanted  in  what  has 
become  popularly  known  as  a  ‘virus,’  and  strict  integrity  has 
been  recognized  as  one  of  the  fev.  effect ive  defenses. 

Flo  re  is  e  glowing  body  of  experience  with  lb" 
iniph  nieiitatioii  and  ec.e  of -'net  integrity  in  highly  ousted 
operating  systems.  I  nr  example,  in  the  Honeywell  SCOMP, 
t  he  first  ( 'lass  A  I  sysl  chi  on  the  Bvaluati  d  Po  m  burls  Gist, 
•.tri't  integrity  is  i.u  bided  as  part  of  the  pro'eetion  for 
segments  'I’ll is  n.r.  bam -in  I  -  used  for  the  protection  for 


security  related  information  such  as  nirii  'at a.  In  addition, 
the  (ieniini  UKMSOS*  has  incorporated  strict  integrity  as 
part  of  the  sensitivity  label  for  all  subjects,  objects,  and 
devices-,  this  approach  has  been  found  useful  when  designing 
the  inlegrttv  protection  both  of  sensitive  application 
information  and  of  system  information  used  to  support  the 
security  controls  themselves.  Although  there  has  been  little 
comparable  experience  in  database  systems,  the  1.1*.  Sharp 
multilevel  database  model8  incorporates  strict  integrity  along 
with  multilevel  secrecy. 

Low-Water  Mark  Policy.  This  policy  is  analogous 
to  the  high-water  mark  security  policy  of  the  ADKPT-aO 
svstemy  A  subject's  integrity  class  is  dynamic  and  decreases 
as  the  subject  reads  data  of  lower  integrity.  If  the  integrity 
classes  of  objects  are  static  (as  in  the  strict  integrity  policy),  a 
subject  will  be  unable  to  write  into  tin  object  with  a  higher 
integrity  class  than  it  has  read,  if  the  object  classes  are 
dynamic.  then  their  integrity  classes  are  possibly  lowered  if 
the  subject  writes  into  the  object.  As  summarized  by  Btba'\ 
“This  poliev.  in  practice,  has  rather  disagreeable  behavior.  . 

.  .  In  a  sense,  a  subject  can  sabotage  (inadvertently)  its  own 
processing  by  making  objects  necessary  for  its  function 
inaccessible  (for  modification).  The  problem  is  serious  since 
there  is  no  recovery  short  of  reinitializing  the  subject. “  To 
the  best  of  our  knowledge,  this  policy  has  not  been  included 
in  any  system  design. 

Ring  Policy  I5y  prohibiting  read-downs  In  integrity 
class,  it  seems  the  strict  integrity  policy  and  the  low-water 
mark  policy  loutd  prove  to  be  quite  restrictive  for  most 
systems,  especially  database  systems.  Because  database 
processes  must  have  both  read  and  write  access  to  user  data, 
system  tables,  index  files,  logs,  and  other  structures  to  answer 
queries  and  update  the  database,  it  would  appear  that  the 
only  workable  assignment  of  inter, rity  classes  is  system  low. 
Because  of  the  rest  riot  ivcitess  of  the  two  preceding  policies, 
Biha  also  introduced  a  more  flexible  policy  called  (he  ring 
policy.  Each  subject  and  object  has  a  fixed  integrity  class, 
and  a  subject  is  only  allowed  to  write  into  objects  whose 
integrity  classes  are  dominated  by  the  subject's  class.  No 
restrictions  are  placed  on  reading,  so  a  subject  can  write  high 
integrity  data  even  if  it  has  read  data  of  a  lower  integrity. 
Unfortunately,  the  relaxation  of  this  policy  makes  the 
integrity  class  of  the  subject  essentially  meaningless,  because 
there  are  no  restrictions  on  even  what  programs  the  subject, 
can  execute.  Thus,  what  would  appear  to  be  a  high  integrity 
subject  can,  without  restriction,  be  executing  erroneous  or 
malicious  programs  that  destroy  the  high  integrity 
information  to  which  the  subject  has  access.  In  reality,  this 
policy  fails  to  meet  the  requirements  for  a  mandatory  policy. 
Moreover,  there  is  no  real  experience  using  this  policy  as  a 
basis  for  mandatory  integrity. 

Multilevel  Security  with  No  Write-Up.  Kxtcmling 
the  Bell  .and  l.al’adttla  model  to  prohibit  ‘  w;  it  tug-lip'  in 
secreev  class  provides  a  limited  form  of  mandatory  integrity. 
In  particular,  this  extended  policy  model  addresses  the  ,wriiiv- 
11  p 1  problem  of  the  mandatory  secrecy  policy,  which  allows  a 
subject  to  write  up  ill  secrecy  class  The  extended  inode! 
Would  prevent  a  SIT  'UK T  subject .  for  example,  from 
inserting  data  labeled  as  I  Of  *-SK<  111  ,T  into  a  niuliib  ve| 
relation  or  from  overwriting  a  T( >l’-SIA  HI) T  element  (which 


it  cannot  observe).  This  approach  appears  to  protect 
subjects  from  lower-level  subjects.  Closer  examination  makes 
it  clear  that-  tins  approach  is  a  case  of  the  ring  policy  just 
addressed  in  which  the  secrecy  labels,  such  as  SKCRKT,  are 
also  used  ns  the  integrity  labels;  the  difference  is  thus  only 
svntaciir  with  no  difference  in  the  results  of  the  policy.  Of 
course,  this  policy  also  has  the  same  weaknesses  as  the  ring 
policy 

Program  Integrity  Policy  The  restrictions  of  the 
strict  integrity  policy  remain  a  com  ern,  so  it  seems  important 
to  try  to  identify  a  more  flexible  but  useful  policy.  The  real 
world  supports  some  notion  of  integrity  class  through  job 
levels  and  chain  of  command.  However,  the  flows  between 
different  levels  (usually  adjacent)  are  bidirectional,  so 
information  flows  both  up  and  down  in  integrity  class. 
Moreover,  the  trust  placed  on  the  information  provided  by 
any  individual  is  often  more  a  function  of  the  individual  than 
position.  The  key  to  the  effective  protection  in  this  context 
is  that  the  individuals  are  trusted  to  make  only  the  desired 
in  xlifications  of  high  integrity  information,  even  though  they 
have  been  exposed  to  information  of  lower  integrity  classes. 

This  same  concept  can  he  applied  to  software  by- 
imposing  more  stringent  requirements  on  assigning  an  object 
containing  executable  code  a  high  integrity  class.  It  seems 
unreasonable  to  assume  that  once  a  program  has  observed 
data  of  low  integrity  that  it  is  incapable  of  writing  data  of 
higher  integrity,  or  because  data  are  entered  by  a  user  of  low 
integrity  into  a  database,  that  indexes  and  other  structures 
on  the  database  must,  be  treated  of  low  integrity  also  -  there 
is  little  relationship  between  the  quality  of  the  data  that  go 
into  a  database  and  the  quality  of  the  system  structures  that 
represent  it. 

This  problem  has  been  approached  by  distinguishing 
read  access  from  execute  access  (which  are  treated  identically 
in  the  preceding  policies).  Based  on  this  distinction,  Shirley 
and  Schell10  have  defined  a  program  integrity  policy  in  which 
a  subject  is  only  allowed  t«-  writ-'  into  objects  of  less  than  or 
equal  integrity  class  and  only  allowed  to  execute  objects  of 
greater  than  or  equal  integrity.  A-.  with  the  ring  policy ,  there 
are  no  restrictions  on  reading.  This  policy  appears  to  he 
better  suited  for  databases  because  the  database  processes 
could  operate  with  a  high  integrity  e'ass,  where  they  would 
be  able  to  read  and  update  the  entire  database.  Users  and 
application  processes  would  lie  assigned  integrity  classes 
reflecting  their  'trustworthiness'.  Furthermore,  Shirley  has 
shown  not  only  that  this  :s  a  mandatory  policy  hut  also  that 
it  is  the  identical  policy  implemented  by  the  hardware 
protection  ring  mechanism  of  Multics  and  several  other 
systems  (no  connection  with  Biba's  use  of  the  term  ‘ring  ), 
rims  there  is  a  substantial  body  of  experience  with  this 
policy,  and  it  has  indeed  been  shown  to  be  quite  useful  ill 
operating  systems  There  is  no  comparable  body  of  direct 
experience  with  database  systems. 

An  even  elnser  look  at  the  program  integrity  policy 
reveals  the  somewhat  unexpected  result  that  it  is  just  a 
special  case  of  the  striet  integrity  policy.  To  understand  this, 
it  should  be  recalled  that  ill  the  Bell  and  LnI’adilla  model 
there  is  the  notion  of  a  trusted  subject. ’  When  interpreted 
fur  integrity,  as  in  the  ease  of  the  strict  integrity  policy,  a 
trusted  subject  is  trusted  exactly  to  be  able  to  read  l-.w 


integrity  informal  inn  without-  damning  the  integrity  of  high 
integrity  data.  This  notion  of  trusted  subject  is  too  coarse 
for  the  problem  at  hand  because  a  trusted  subject  can  read 
anv  integrity  class.  However,  the  notion  has  been  refined  in 
the  Gemini  GK.MSOS'  to  identify  a  ‘multilevel  subject'  that 
has  both  a  minimum  and  maximum  class.  Now,  if  the 
subject  in  each  protection  ring  is  regarded  as  multilevel  (with 
respect  to  integrity  classes)  with  a  maximum  integrity  equal 
to  the  ring  of  execution  and  a  minimum  integrity  equal  ‘o  the 
least  trusted  ring,  the  strict  integrity  policy  in  this  case 
becomes  the  program  integrity  policy  if  the  multilevel  subject 
is  trusted  not  to  execute  any  program  with  a  lower  integrity 
class  than  its  maximum. 

Domains  and  Types  Domains  and  types  have  been 
proposed  as  a  means  to  specify  a  mandatory  integrity  policy, 
as  illustrated  by  the  Honeywell  SAT  system1.  Here,  eaeli 
object  is  typed,  and  each  domain  has  a  list  of  types  that  it 
can  observe  and  modify  plus  a  list  of  domains  that  it  can  call. 
Although  this  policy  model  is  similar  to  discretionary  policies 
based  on  the  access  matrix  model,  the  set  of  types,  domains, 
and  rights  cannot  be  altered.  Because  it  is  a  relatively  new 
approach,  its  properties  are  not  yet  completely  clear.  So  far. 
there  is  no  experience  applying  this  type  of  policy  to  a 
database  system,  although  Honeywell  is  working  on  it. 

Discretionary  Integrity  Authorization 

Discretionary  integrity  authorization  policies  control 
access  to  data  at  the  user  or  user  group  level.  The  usual 
approach  to  controlling  access  in  database  systems  includes 
authorisation  lists,  which  specify  what  operations  a  user  (or 
group)  is  authorized  to  perform  on  some  set.  of  data.  I’or 
integrity,  the  operations  of  interest  include  update,  insert, 
and  delete. 

The  authorization  lists  of  database  systems  are  included 
in  the  data  model  at  different,  layers  of  abstraction.  At  the 
lowest  layer,  they  are  associated  with  files,  records,  or 
elements.  At  th"  highest  layer,  they  are  associated  with 
views  or  subschema  on  the  data.  The  high-level  approach 
has  the  advantage  of  specifying  a  context  for  access.  The 
context  —  i  e..  exact  set.  of  elements  that  fall  within  the  target 
of  a  view  -  is  dynamic,  changing  ns  the  underlying  database 
is  updated.  Because  it  is  easier  and  more  natural  for  Users, 
the  high-level  approach  has  proven  to  be  far  more  useful  than 
the  low-level  approach,  and  is  embodied  in  many  systems 
including  sqi,/])H.  1)11*2,  OKACI.K.  and  INGRES  (though  in 
a  scum  what  different  form). 

The  discretionary  security  policy  contained  in  the 
Trusted  Computer  System  Kvaluat i"ti  Criteria'  is 
appropriate  for  database  systems  ns  long  as  the  concept  of 
object  is  interpreted  to  mean  views  (actually  view 
Speeifirat  lolls  or  subschema)  ratlier  than  lust  physical 
elements,  records,  or  files.  Note  that  this  does  noi  mean  that 
discretionary  controls  cannot  he  associated  with  individual 
records  and  elements;  such  controls  are  easily  defined  as 
a  lews  on  I  he  da  t  abase 

The  Criteria  specify  that  disc  ret  e  ■nary  con!  r-ds  are  to 
he  applied  to  each  named  object There  is  no  ,  ■  qiiireiiinit 
that  the  named  objects  be  disjoint  m  memory  and  in  some 
opt  rating  sisii  ns  a  file  may  tie  are,,  .sed  v  in  different  pal  h 


names  through  different  directories  with  different 
discretionary  authorizations  placed  on  the  different  names. 
Similarly,  applying  discretionary  controls  to  views  is 
consistent  with  the  Criteria  because  views  are  just  a  way  of 
naming  objects  Also,  there  is  no  requirement  that  the 
'named  objects'  of  the  discretionary  policy  be  the  same 
objects  or  even  at  the  same  layer  of  abstraction  as  the 
‘storage  objects'  of  the  mandatory  policy. 

CONSISTENCY  INTEGRITY 

Database  Integrity  Rules 

Database  integrity  rules  protect  a  database  from  data 
entry  errors  as  well  as  from  other  errors  made  by  the 
operator  or  by  software  They  define  the  correct  states  of 
the  database  and  may  specify  actions  to  take  if  ail  update 
would  cause  the  database  to  enter  an  incorrect  state.  They 
are  similar  to  exception  conditions  built  into  programs, 
excejit  that  the  conditions  are  represented  in  the  database  (as 
metadata)  rather  than  in  the  application  programs  so  that 
they  can  he  automatically  applied  to  all  transactions 
updating  the  database. 

In  a  relational  system,  there  are  two  common  types  of 
database  integrity  rules:  domain  integrity  rules  and 
relational  integrity  rules.  Domain  integrity  rules  are 
context-free  rules  specifying  the  allowable  set  of  values  (i.e., 
domain)  for  an  attribute,  e  g  .  DRIVKR.AGH  is  greater  than 
lb  but  less  than  100.  Relational  integrity  rules  arc  context- 
sensitive  rules  specifying  more  global  constraints  on 
individual  tuples  or  sets  of  related  tuples,  e.g.,  that  every 
tuple  in  a  I’R( IGRAMMKR  relation  has  a  corresponding 
tuple  m  an  KMI’I.OYKK  relation  (this  is  a  form  of  referential 
integrity ').  Many  relational  systems,  c.g..  INCURS,  provide 
mocha n isms  whereby  users  can  define  rather  complex 
integrity  rules. 

Integrity  rules  play  a  vital  pari  in  ensuring  I  ho  integrity 
nf  a  database.  Indeed,  they  are  a  very  important  part  of 
access  controls  because  most  systems  are  vulnerable  to  errors 
as  well  as  to  sabotage.  It  is  probably  fair  to 'ay  that  a 
database  system  would  not  be  regarded  as  a  useful  trusted 
system  if  it  does  not  support  integrity  rules 

There  are.  however,  intrinsic  problems  associated  with 
integrity  rules  in  a  multilevel  system  that  is  rated  at  the 
evaluation  level  of  112  or  higher,  arising  from  the  requirement 
to  protect  against  covert  channels.  Because  the 
implementation  of  integrity  rules  is  outside  the  mandatory 
security  perimeter,  the  database  subjects  that,  enforce  the 
integrity  rules  must  lie  denied  access  to  data  that  is  classified 
higher  than  the  subject  level.  Thus,  if  the  subjects  are 
processing  a  t  rans.actimi  mi  behalf  of  a  user,  the  only  data 
visible  in  those  subjects  will  data  that  is  classified  at  a 
level  dominated  by  the  user's  icvcl  If  the  database  system 
were  given  access  to  data  not  dominated  by  the  user's  level, 
then  a  Trojan  Horse  in  the  database  system  cotlld  leak  the 
unauthorized  data  -  that  is.  unless  the  database  system  (or  a 
large  portion  thereof)  were  part  of  the  mandatory  security 
perimeter  Because  the  latter  Is  neither  feasible  m>r 
desirable,  in  multilevel  systems  rated  at  the  h'Vel  of  B2  or 
higher,  we  are  forced  to  consider  integrity  constraints  as 
'njistra nits  mi  the  subset  of  the  database  nominated  by  the 
u r’s  clearance. 


To  see  how  this  revised  interpretation  of  integrity 
constraints  affects  the  enforcement  of  integrity  rules,  consider 
the  relational  model,  which  requires  each  tuple  in  a  relation 
to  have  a  unique  primary  key.  Suppose  the  tuples  in  a 
multilevel  relation  arc  classified  SIX'RKT  or  TOP-SFX'RKT, 
and  suppose  the  relation  contains  a  TOR-SKCRKT  tuple 
with  primary  key  I  OO.  This  tuple  will  he  invisible  to 
subjects  operating  on  behalf  of  SKCRKT  users.  Tims,  if  a 
SIX'RKT  user  attempts  to  insert  a  n‘*w  tuple,  also  with  key 
FOO,  the  system  will  aerept  the  tuple.  Because  the  access 
class  becomes  the  only  means  of  distinguishing  the  tuples,  the 
class  must  then  be  considered  to  hr  part  of  (be  primary  key. 
We  refer  to  the  coexistence  of  multiple  tuples  with  the  same 
primary  key  except  for  access  class  as  polyinstantiateJ 
tuples11 

Problems  also  arise  with  respect  to  referential  integrity. 
For  example,  suppose  a  TOP-SIX  RIOT  user  creates  a  TOP- 
SI/  RIOT  tuple  in  a  relation  T(II),  A),  which  is  associated 
with  a  SIX'RKT  tuple  in  a  relation  S(ID,  II)  through  the  join 
attribute  ID.  The  relation  S  represents  the  entities  named  by 
the  primary  key  ID.  If  a  SIX'RKT  user  deletes  the 
referenced  tuple  in  S,  referential  integrity  will  be  violated. 

But  because  the  SI'X'RIOT  user,  as  well  as  all  subjects  that 
run  on  that  user's  behalf,  cannot  know  of  the  existence  of  the 
TOR-SKCRKT  tuple,  this  cannot  he  avoided. 

As  a  third  example  of  the  problems  that  arise  from 
invisible  data,  consider  a  relation  that  contains  the  weights  of 
items  on  board  various  flights.  Suppose  there  is  maximum 
weight  restriction  of  5000  for  any  given  flight  and  that  some 
of  the  items  on  board  a  flight  are  classified  SIX'RKT  while 
others  are  TOR-SIX'RKT  If  the  integrity  constraint  is 
specified  simply  as  an  upper  bound  of  5000  for  the  total  of  all 
weights  for  a  flight,  a  flight  could  be  overloaded  because  the 
TOP-SI  X 'RIO  T  weights  w  mid  be  invisible  when  the 
constraint  is  applied  a(  t lie  SIX'RKT  level  to  determine 
whether  an  additional  SIX ’BIOT  item  can  be  placed  on  board 
A  possible  solution  is  to  have  separate  constraints  for 
SIX’RKT  ami  TOP-SIX ‘RIOT  weights. 

Thus,  in  |!2  or  higher  systems,  the  consistency  defined 
by  integrity  constraints  must  be  interpreted  with  respect  to 
the  secrecy  class  of  the  subject  applying  (lie  constraint. 
However,  whether  there  should  be  some  notion  of  inter-level 
consistency,  or  how  this  might  be  specified,  is  unclear.  It  is 
also  unclear  how  triggers  fit  into  this  notion  since  a  trigger 
activated  by  an  operation  on  behalf  of  a  user  having  one 
secreey  ela.ss  cannot  read  up  or  write  down  in  secrecy  class. 
Finally,  we  note  that  if  the  database  is  poly-instantiated  at 
the  tuple  or  element  level,  problems  arise  in  applying  the 
integrity  constraints  because  more  Ilian  one  tuple  or  clement 
with  different  values  may  be  selected  by  the  constraint,  each 
with  different  outcomes  Thus,  the  integrity  rules  must 
specify  which  values  to  select  among  polyinstaiil  luted  values. 

Ill  a  multilevel  system,  the  concept  of  integrity 
const  lain  is  should  also  be  extended  to  include  const  mints  mi 
the  classifications  assigned  to  data.  I  or  relational  systems, 
we  have  found  Hint  several  properties  should  bold: 

•  Tin-  ei unpb'i e  definition  (schema)  for  a  relation. 

unhiding  the  names  ,,f  :i||  attributes,  should  have 

a  single  access  class  (bat  is  ibuniliat  "d  by  I  lie 


access  classes  of  all  data  that  is  to  go  into  the 
relation.  Integrity  rules  that  constrain  the  data 
going  into  the  relation  should  also  be  assigned  this 
access  class. 

•  The  attributes  representing  the  primary  key  in  a 
relation  should  be  uniformly  classified  —  that  is, 
within  any  given  tuple,  the  elements  forming  the 
primary  key  should  have  the  same  access  class. 

•  The  classification  of  the  primary  key  should  bo 
dull’ Plated  by  the  classifications  of  all  other 
elements  wit  hill  a  tuple. 

In  that  integrity  rules  enforce  constraints  on  the 
relationships  among  data  in  the  database,  they  can  be 
associated  with  inference  problems.  For  example,  if  an 
integrity  constraint  states  that  ('  =  A  +  B  for  attributes  A, 
B,  and  0,  where  A  and  B  are  SIX-RIOT  but  C  is  TOP- 
SlX'RKT,  then  a  SKCRKT  user  with  access  to  A,  B,  and  the 
integrity  constraint  can  infer  C.  In  this  particular  case,  the 
best  strategy  for  dealing  with  the  problem  may  be  to  use  the 
integrity  constraint  to  force  classifications  on  tlic  data  to 
prevent  the  inference  —  e  g.,  classify  A  or  IS,  or  both,  as 
TOP-SIX 'Birr.  In  eases  w  here  the  rule  of  inference  is 
complex  and  unknown,  it  may  be  more  appropriate  to 
classify  the  integrity  constraint,  (which  can  be  viewed  as  an 
inference  rule). 

In  summary,  although  a  multilevel  secure  database 
system  should  provide  database  integrity  rules,  the 
mandatory  secrecy  policy  affects  the  interpretation  and 
application  of  integrity  constraints. 

Recovery  Management 

Another  vital  aspect  of  database  integrity  is  protecting 
the  database  from  operator  or  software  errors,  including 
system  crashes.  The  accepted  method  of  dealing  with  such 
errors  and  faults  is  based  on  the  concept  of  a  trail. tael  ion, 
which  is  a  sequence  of  operations  that  behaves  atomically  — 
that  is.  it  either  successfully  completes  [ronwiil-t)  all  updates 
or  else  it  lias  no  effect  on  the  state  of  the  database  ( mils 
bark).  The  overall  integrity  policy  for  trusted  systems  should 
include  the  concept  of  transact  urns  wit  li  commit  and  roll¬ 
back. 

Multilevel  updates  raise  some  difficult  issues  regarding 
transaction  management.  For  example,  if  a  trusted  user  ran 
simultaneously  insert  or  update  multilevel  data  (within  the 
user  s  range  of  trust),  it  may  be  desirable  to  decompose  t hose 
updates  into  single-level  updates  represented  as  single-level 
transactions  and  performed  by  single-level  database  subjects. 
However,  tlie  unit  itself  must  also  be  treated  as  a  transaction, 
so  the  concept  of  a  multilevel  transaction  with  single-level 
nested  transactions  appears  to  lie  very  useful.  The  problem 
is  rolling  hack  the  low  port  ions  of  the  i  ransactinn  if  the  high 
port  i  uis  fail. 

Assuming  recovery  management  js  outside  of  the 
mandatory  security  perimeter,  it  is  not  clear  how  the 
database  recovery  log  should  be  managed  and  processed  ill 
systems  that  all-  rated  at  the  level  of  I ?2  or  higher.  However, 
some  of  the  techniques  used  for  general-purpose  operating 
systems  to  ensure  the  consistency  of  file  systems  during 


backup  and  recovery  may  be  useful. 

Concurrency  Controls 

An  important  aspect  of  database  integrity  is  ensuring 
that  concurrent  transactions  do  not  interfere  with  each  other, 
giving  rise  to  inconsistent  states  of  the  database. 

Serial*  : ability,  which  states  that  any  transaction  schedule 
must  he  equivalent  to  one  in  which  the  transactions  execute 
serially,  has  been  shown  to  he  a  necessary  and  sufficient 
condition  for  global  consistency'",  although  there  are  systems 
that  enforce  somewhat  weaker  policies.  Some  notion  ol 
global  consistency,  however,  is  an  essential  aspect  of  the 
overall  integrity  policy  for  trusted  database  management 
systems.  The  concurrency  policy  should  also  address  the 
problems  of  deadlock,  where  multiple  transactions  cannot 
proceed  because  they  are  waiting  oil  each  other,  and  hvcloek, 
where  a  transaction  never  exits  from  a  wait  state,  both  of 
whit  h  create  <h  nial-of-service  problems. 

In  B2  or  higher  systems,  the  concurrency  imahamsms 
must  use  techniques  other  than  simple  locks  because  read- 
write  locks  on  multilevel  data  provide  a  signalling  channel. 

Event  counters1''  are  not  vulnerable  to  covert  channels,  hut 
require  that  higher-level  transactions  roll  hack  when  a  lower- 
level  one  causes  an  update  that  could  interfere  with  its 
behavior. 

CONCLUSIONS 

We  do  not  know  enough  about  the  application  of 
mandatory  integrity  policies  to  databases  to  recommend  any 
one  in  particular  or  even  state  that  one  he  mandated  at  all. 

While  the  strict,  integrity  policy  without  trusted  subjects  may¬ 
be  appropriate  for  some  threat  environments,  the-  more 
flexible  program  integrity  policy,  which  uses  restricted 
trusted  subjects  to  manage  a  database,  may  be  nppioprialc 
for  most  environments.  It  would  be  premature  to  adapt  a 
particular  mandatory  policy  in  criteria  for  t rust o  t  database 
systems  until  such  a  policy  has  been  experimentally  tried  in 
at  least  one  operational  environment  and  has  been 
demonstrably  successful.  On  the  other  hand,  a  discrete  nary 
policy  along  the-  lines  of  that  given  in  the  criteria  is  cxln  melv 
useful  provided  it  is  interpreted  to  apply  to  views  rather  than 
just  elements,  records,  or  files. 

Database  integrity  rules  should  be  included  in  an 
overall  integrity  policy  because  they  provide  Users  with 
considerable  assurance  that,  the  data  is  protected  against 
many  errors  This  is  one  of  the  best  ways  ill  which  the  users 
themselves  can  greatly  enhance  the  integrity  of  their  data. 
However,  the  interpretation  and  application  of  integrity  rules 
is  const  rained  by  the  requirements  for  mandatory  security 
Similarly,  any  trusted  system  should  support  the  concepts  of 
atomic  transactions,  recovery,  and  noninterference,  though 
again  the  features  are  constrained  by  the  mandatory  security 

requirements. 

Although  we  believe  it  is  vital  for  trusted  systems  to 
support  these  different,  integrity  policies,  it  is  neither 
necessary  imr  possible  to  have  the  same  degree  of  assurance 

ill  the  enforeeiiient  of  (hern  all  \\  herc-as  < 'lasses  A  ami  if  are 

appropriate  for  mandatory  access  rout  mis,  (lass  ('2  is 
appropriate  for  discretionary  controls  am!  consistency 
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controls,  which  are  considerably  more  complex  than 
mandatory  controls  and  require  much  of  the  database  system 
for  their  support. 

To  provide  a  high  degree  of  assurance,  the  mandatory 
integrity  policy  must  be  enforced  by  the  reference  monitor. 

In  addition  to  enforcing  the  mandatory  secrecy  policy,  the 
reference  monitor  ensures  the  integrity  of  all  data  in  the 
system,  including  the  labels  that  represent  the  secrecy  and 
integrity  access  classes.  If  the  data  are  vulnerable  to 
tampering  during  Morn  ■  or  transmission  to  and  from  the 
reference  monitor,  cryptographic  checksums  may  be  used  to 
ensure  the  integrity  of  the  data  and  its  labels.  Tor 
cryptographic  checksums  to  he  meaningful,  it  is  essential  that 
the  processes  that  compute  and  validate  the  checksums  and 
manage  the  key  lie  under  the  strict  control  of  a  reference 
monitor 
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INTRODUCTION 

In  January  of  1981,  the  Department  of  Defense 
Computer  Security  Center  (DoDCSC)  was  formed 
to  study  all  aspects  of  computer  security  and  to 
promote  the  development  of  trusted  computer 
systems.  Their  first  task  was  to  develop  a  set  of 
criteria  for  defining  what  "trusted"  meant,  and  for 
assigning  levels  to  define  how  "trusted"  a  system  is. 
Their  first  criteria,  the  "Department  of  Defense 
Trusted  Computer  System  Evaluation  Criteria 
[TCSEC]",  was  published  in  August  of  1983.  The 
"Department  of  Defense  Trusted  Network 
Evaluation  Criteria  [TNEC]",  expected  out  in  1986, 
deals  with  network  security  issues. 

This  paper  will  discuss  the  software  and  hardware 
components  which  must  be  present  in  order  for  a 
Database  Management  System  (DBMS)  to  be 
considered  "trusted"  in  relation  to  the  [TCSEC], 
Distributed  databases  utilizing  the  TNEC  will  be 
considered  beyond  the  scope  of  this  paper. 

Kev  Security  Concepts 

Several  concepts  must  be  addressed  before  any 
discussion  of  computer  security  can  be  made.  The 
following  paragraphs  provide  a  general  overview  of 
these  concepts  so  that  later  references  to  them  may 
be  understood. 

The  term  "Trusted  Computer  System"  is  defined  in 
the  [TCSEC]  as  "a  system  that  employs  sufficient 
hardware  and  software  integrity  measures  to  allow 
its  use  for  processing  simultaneously  a  range  o! 
sensitive  or  classified  information."  In  other  words  a 
user  running  at  the  Unclassified  level  can  share  the 
system  with  users  running  Top  Secret,  while 
ensuring  that  each  user  can  access  only  those 
items  for  which  they  have  permission 

The  reference  monitor  concept  developed  from  a 
study  performed  (or  the  Air  Force  by  James  P. 
Anderson  8  Company.  Simply  stated,  tfm  concept 
stipulated  that  was  that  "a  reterence  monitor  which 
enforces  the  authorized  access  relationships 
between  subjects  and  objects  of  a  system"  should 
exist.  The  mechanism  that  performs  this  concept  is 
called  a  validation  mechanism,  and  must  meet  the 
following  fhree  requirements: 

a.  "The  reference  validation  mechanism 
must  be  tamper  proof. 


b.  The  reference  validation  mechanism 
must  always  be  invoked. 

c.  The  reference  validation  mechanism 
must  be  small  enough  to  be  subject  to 
analysis  and  tests,  the  completeness  of 
which  can  be  assured." 

This  validation  mechanism  is  given  the  name  of  the 
Trusted  Computing  Base  (TCB)  and  is  sometimes 
referred  to  as  a  security  kernel. 

The  following  excerpt  from  the  mandatory  security 
control  policy  defined  in  the  [TCSEC]  adequately 
defines  the  policy's  meaning:  "(the  TCB)  must 
include  a  set  of  rules  for  controlling  access  based 
directly  on  a  comparison  of  the  subject's  clearance 
or  authorization  for  the  information  and  the 
classification  or  sensitivity  designation  of  the 
information  being  sought,  and  indirectly  on 
considerations  of  physical  and  other  environmental 
factors  of  control." 

Likewise,  the  control  policy  for  discretionary 
security  policy  states  that  the  TCB  "must  include  a 
consistent  set  of  rules  for  controlling  and  limiting 
access  based  on  identified  individuals  who  have 
been  determined  to  have  a  need-to-know  for  the 
information.” 

TRUSTED  COMPUTER  SYSTEM 
EVALUATION  CRITERIA 

While  this  does  not  primarily  address  database 
security  issues,  it  will  be  discussed  since  it  presents 
some  key  concepts  that  are  applicable  to  any 
multilevel  secure  software  product. 

Fundamental  Security  Requirements 

The  criteria  presents  six  fundamental  computer 
security  requirements  broken  into  three  main 
categories  of  policy,  accountability,  and  assurance. 
Each  of  these  requirements  is  presented  below  with 
its  rationale. 

The  first  two  requirements  deal  with  policy.  The  first 
requirement  states  that  there  must  be  an  explicit 
and  well-defined  security  policy  enforced  by  the 
system  As  will  be  seen  in  the  evaluation  class, 
there  are  two  types  of  policy  --  mandatory  for 
access  rules  to  sensitive  objects,  and  discretionary 
for  allowing  access  by  groups  or  individual  users. 
For  a  mandatory  security  policy  to  work  each  object 


within  the  system  must  have  an  associated  security 
label-  This  is  the  second  requirement. 

The  third  and  fourtn  requirements  focus  on 
accountability  factors.  The  idea  is  that  each  subject 
in  the  system  will  be  identified  and  that 
security-related  actions  can  be  audited  and  traced 
back  to  the  responsible  party. 

The  last  two  requirements  deal  with  assurance. 
This  means  that  there  is  some  way  to  guarantee 
that  the  first  four  requirements  are  enforced  and  that 
they  are  continuously  protected  against  tampering 
and/or  unauthorized  changes. 

Division  Ratings 

When  a  computer  system  is  evaluated  by  the 
DoDCSC,  it  is  assigned  .a  rating.  The  rating 
consists  of  a  division  letter  and  a  class  number.  The 
heirarchy  of  division  and  class  numbers  is  as 
follows:  the  lower  the  division  letter  the  higher  the 
protection  the  system  gives.  As  the  class  numbers 
increase  within  a  division  so  does  the  security 
rating.  Thus  a  rating  of  B1  is  higher  than  a  rating  of 
C2  thus  affording  more  protection.  A  key  feature  of 
the  security  ratings  is,  that  inherited  in  the 
requirements  for  a  particular  class  are  all  the 
requirements  for  any  clasess  lower  than  it  in  the 
hierarchy. 

Division  "D”  contains  only  one  class  and  is  used 
only  when  a  system  that  is  evaluated  does  not  fall 
in  any  of  the  higher  classes. 

All  classes  in  division  "C"  implement  some  type  of 
discretionary  security  policy.  This  will  enforce  a 
need-to-know  type  of  protection  on  users  and 
objects.  Accountability  is  another  feature  and 
requires  that  certain  audit  capabilities  be 
Implemented. 

A  division  "B"  rating  requires  addition  of  a 
mandatory  security  policy.  This  policy  requires 
sensitivity  labels  for  all  objects  to  be  part  of  the 
major  data  structures  of  the  system.  Thus,  the 
mandatory  security  policy  supplementary  to  the 
discretionary  policy  developed  for  the  division  C 
systems.  In  addition,  the  system  developer  must 
provide  the  model  of  the  security  policy  that  the 
TCB  is  based  on.  along  with  its  specification.  The 
developer  must  also  provide  evidence  that  the 
reference  monitor  concept  has  been  implemented. 

For  a  system  to  receive  a  division  "A”  rating,  it  is 
required  that  the  mandatory  and  discretionary 
security  policies  can  be  formally  proven.  The  TCB  is 
guaranteed  that  it  meets  its  security  requirements  in 
all  phases  of  design,  development,  and 
implementation.  This  guarantee  is  the  result  of 
adding  formal  methods  into  the  design  process. 

TRUSTED  DATABASE  DESIGN 

The  need  for  a  trusted  DBMS  arises  from  the  fact 
that  the  [TCSEC]  enforces  access  controls  only  to 


the  granularity  of  a  file.  To  make  maximum  use  of  a 
computer  and  its  associated  databases,  these 
access  controls  must  be  expanded  to  arbitrate 
accesses  to  a  finer  detail,  such  as  to  the  field  or 
data  element  level. 

The  remainder  of  this  paper  will  first  discuss  the 
security  threats  to  a  DBMS,  then  proceed  to  present 
some  of  the  suggested  approaches. 

Security  Threats 

Two  security  threats,  inference  and  aggregation, 
are  prevalant  in  DBMS  systems.  In  addition,  there 
are  those  threats  which  can  be  found  in  any  type  of 
computer  program,  Trojan  Horses  and  Covert 
Channels. 

Inference,  as  the  name  implies,  occurs  when  the 
user  is  able  to  infer  some  fact  from  the  information 
that  has  been  presented.  Suppose,  for  example, 
that  a  database  has  two  relations:  AIRCRAFT,  with 
attribulas  ID  and  PAYLOAD;  and  WEAPONS,  with 
attribute  TYPE  and  ID. The  fields 
AIRCRAFT. PAYLOAD  and  WEAPONS. ID  can  be 
joined.  All  records  are  SECRET  unless  the 
WEAPON  TYPE  is  NUCLEAR  in  which  case  it  is 
TOP  SECRET.  Now  consider  the  following  query: 

RETRIEVE  AIRCRAFT.ID 
WHERE  Al RCRAFT. PAYLOAD  =  WEAPON. ID 
AND  WEAPON. TYPE  =  "NUCLEAR" 

The  query  would  be  processed  and  would  return  to 
the  SECRET  user  a  list  of  all  aircraft  having  a 
nuclear  payload,  thus  revealing  TOP  SECRET 
information.  This  occurs  because  the  computer 
treats  the  information  returned  as  SECRET  since 
the  TOP  SECRET  portion  was  stripped  away  in  the 
selection. 


Aggregation  occurs  when  data  combined  from 
different  sources  results  in  a  data  item  that  has  a 
higher  classification  than  its  individual  components. 
This  can  be  the  result  of  using  one  of  the  aggregate 
operations,  such  as  sum,  or  can  be  intrepreted  as 
the  user,  infering  from  different  database  requests, 
the  data  at  a  "higher"security  level.  For  instance,  in 
the  previous  example  suppose  that  all  records  were 
SEORFT  but  the  fact  that  a  particular  aircraft  was 
carrying  a  nuclear  payload  (i.e.,  the  join  relation)  is 
TOP  SECRET.  By  placing  two  queries  a  SECRET 
user  could  determine  what  the  payload  (TOP 
SECRET)  was. 

Other  Security  Threats  A  DBMS  would,  like  its 
operating  system  counterpart,  have  to  concern  itself 
with  the  problems  of  Trojan  Horses  and  Covert 
Channels.  The  [TCSEC]  defines  these  two  terms 
as: 

Trojan  Horse  -  "A  computer  program  with  an 
apparently  or  actually  useful  function  that 
contains  additional  (hidden)  functions  that 
surreptitiously  exploit  legitimate 
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authorizations  of  the  invoking  process  to  the 
detriment  of  security." 

Covert  Channel  -  "A  communication  channel 
that  allows  a  process  to  transfer  information 
in  a  manner  that  violates  the  system's 
security  policy." 

As  can  be  seen  from  their  definition  care  must  be 
taken  to  prevent  the  occurence  of  these  security 
threats. 

Architectures 

With  the  objective  of  having  a  Multilevel  DBMS 
(MDBMS)  and  knowing  the  types  of  threats  to  the 
system,  several  potential  architectures  have  been 
put  before  the  community  as  potential  solutions. 
These  architectures  are  presented  below. 

It  should  be  noted  that  whatever  architecture  is 
used,  the  concepts  defined  in  the  [TCSEC]  will 
prevail.  Each  will  contain,  in  some  part,  a  TCB  in 
which  resides  the  security-related  code  that  is 
guarenteed  to  work.  Depending  on  the  MDBMS.  it 
will  contain  code  to  enforce  mandafory  and 
discretionary  security  policies.  Marvin  Schaefer 
[SCHA85]  states  in  his  paper  that  the  [TCSEC]  is 
sufficient  in  its  current  form  to  handle  the  multilevel 
database  management  problem,  since  each 
operating  system  maintains  some  type  of  internal 
database  to  keep  track  oi  i*®  information. 

Another  key  point  is  that  all  accesses  to  the 
database  must  be  through  the  DBMS;  otherwise, 
security  is  circumvented.  This  can  be  accomplished 
by  making  the  database  a  special  classification  that 
can  only  be  accessed  from  the  DBMS  which 
operates  at  that  level. 

Views  The  concept  of  views  has  been  around 
since  the  early  days  of  DBMS.  In  1983,  Billy 
Claybrook  [CLAY83]  presented  a  method  for  using 
views  to  enforce  security  requirements  on  a  DBMS. 
A  view  is  defined  in  [CLAY83]  as  "a  database 
description  (or  definition),  together  with  an  instance 
of  the  definition.”  A  view  definition  "is  'he  process  of 
specifing  the  attributes  of  a  view  and  defining  the 
mapping  between  the  view  and  the  underlying 
database." 

The  concept  that  a  view  utilizes  is  that  a  user  is 
given  access  to  a  view  but  not  the  data  itself  so  that 
the  user  will  only  be  able  to  access  what  the  view 
"sees."  In  addition,  a  view  could  be  defined  in  terms 
of  another  view  allowing  for  a  breakdown  of  the 
component  of  the  database  tuples.  The  security 
classification  can  be  either  static  or  dynamic 
depending  on  to  what  depth  the  security  labeling  is 
taken. 

A  problem  with  this  architecture  its  side  effects  due 
to  the  fact  that  the  user  only  sees  a  part  of  the  tuple 
For  instance,  if  a  user  has  delete  permission  to  a 
tuple  and  subsequently  deletes  a  tuple  that  was  in 
the  users  view,  what  should  be  done  with  those 


attributes  that  were  contained  in  the  actual  view  but 
not  "seen"  by  the  user? 

The  [CLAY83]  paper  presents  the  author’s  method 
for  handling  the  inference  and  aggregation 
problems.  The  solution  to  the  inference  threat  was 
to  make  sure  that  the  user  had  the  necessary 
clearance  for  at  least  the  highest  object  searched. 
Likewise,  the  solution  presented  for  aggregation 
called  for  the  user's  clearance  to  match  the  highest 
classification  in  the  material  searched. 

Integrity-Lock  Richard  Graubart  has  presented 
several  papers  ([GRAU84],  [GRAU85])  on  an 
architecture  called  Integrity-Lock.  This  architecture 
was  an  outgrowth  of  the  1982  Summer  Study  on 
Database  Security  sponsored  by  the  Air  Force 
Studies  Board.  Its  key  architectural  concept  is  to  be 
able  to  retrofit  security  onto  existing  DBMS  instead 
of  recreating  the  DBMS  from  scratch. 

The  Integrity-Lock  approach  calls  for  the  database 
management  system  to  be  separated  into  three 
components.  Graubart's  conception  of  this  is  shown 
in  Figure  1 .  The  trusted  code  resides  in  the  Trusted 
Front  End  (TFE).  The  TFE  is  responsible  for 
authenticating  the  user,  and  verifying  that  only 
information  that  the  user  is  entitled  to,  is  passed 
back  to  him.  The  Untrusted  Front  End  (UFTE)  takes 
care  of  parsing  the  queries  and  formatting  the 
output  for  the  user.  Lastly,  the  Untrusted  DBMS 
handles  all  the  I/O  access  to  the  actual  database. 

The  [GRAU84]  paper  goes  on  to  define  the  basic 
theme  of  the  Integrity-Lock  architecture;  that  is  each 
tuple  has  at  least  one  classification  attribute  and  an 
associated  cryptographic  checksum.  This  provides 
a  mechanism  tor  labeling  the  classification  of  the 
data  and  provides  a  way  to  detect  unauthorized 
modifications  to  the  tuple.  The  checksum  is 
computed  using  the  value  of  the  tuple  and  its 
classification  as  input  to  an  "unbreakable" 
encryption  algorithm.  The  result  is  placed  with  the 
tuple  in  the  database.  Should  an  unauthorized 
modification  be  made  to  the  data,  the  checksum  will 
not  match  and  a  security  violation  flagged.  Dorothy 
Denning,  in  her  1984  paper  [DENN84],  presents 
just  how  these  checksums  cc  l  be  computed  along 
with  their  strengths  and  weaknesses. 

The  g-anula.-it,  ui  the  security  level  can  be 
increased  anywhere  from  the  tuple  level  to 
individual  attributes  by  the  addition  of 
classification/checksum  pairs.  Of  course  the  greater 
the  granularity,  the  greater  the  cost;  in  terms  of  CPU 
power  to  compute  the  checksums,  and  the  amount 
ot  disk  space  require  to  save  the  database. 

One  of  the  key  advantages  of  this  architecture  is 
that  the  technology  needed  to  implement  it  currently 
exists.  It  can  be  retrofitted  on  to  an  existing  DBMS 
to  reduce  the  cost  and  time  required  tn  havp  a 
Multilevel  DBMS  in  the  marketplace. 
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CONCLUSION 


This  paper  has  presented  an  overview  on  the 
development  of  "trusted  databases."  It  has 
discussed  the  threats  to  such  a  database  and  has 
presented  a  brief  overview  of  some  of  the  current 
ideas  for  a  likely  architecture.  While  each  has  its 
own  strengths  and  weaknesses,  time  will  tell  which, 
if  either,  will  be  the  final  solution. 


These  designs  have  dealt  with  the  implementation 
of  the  mandatory  security  policy  onto  an  existing 
DBMS.  Further  work  still  needs  to  be  done  on  how 
to  implement  the  discretionary  security  policy  of 
need-to-know  onto  a  database,  be  it  either  at  the 
database  level  or  at  the  level  of  individual 
attributes. 
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INTRODUCTION 

Honeywell  Information  Systems  has  the 
only  two  commercial  products  on  the  National 
Computer  Security  Center's  (NCSC)  Evaluated 
Products  List  above  class  C2 .  The  Multics 
Product  is  rated  as  a  class  B2  and  the  Scomp 
is  the  only  system  to  receive  the  highest 
rating  of  class  Al .  These  systems  are  used 
in  a  variety  of  applications  where  security  is 
a  key  requirement.  Several  new  developments 
are  underway  to  further  demonstrate  the 
effective  use  of  the  Scomp  to  meet  a  variety 
of  market  needs  . 

As  a  result  of  the  experience  with 
Multics  and  Scomp,  Honeywell  is  developing  a 
strategy  and  product  direction  to  expand  our 
segment  of  the  evolving  security  market.  The 
security  market  consists  of  several  elements 
which  must  be  integrated  into  a  coordinated 
set  of  product  and  service  offerings. 

This  paper  will  present  a  view  of  the 
security  market  and  discuss  the  initial 
approach  being  taken  to  develop  products  to 
meet  these  market  needs. 

BACKGROUND 

Honeywell  has  long  been  committed  to  the 
development  of  systems  to  meet  the  security 
needs  of  government  and  industry.  The  de¬ 
velopment  in  the  early  1980's  are  key  examples 
of  this  effort.  Bringing  trusted  products  to 
the  marketplace  has  provided  Honeywell  with  a 
unique  view  of  security  market  requirements. 
The  advent  of  the  Trusted  Computer  System 
Evaluation  Criteria  and  overall  awareness  of 
trusted  system  concepts  has  grown  rapidly  dur¬ 
ing  this  period.  The  list  of  vendors  now 
working  with  the  NCSC  is  a  relative  who's  who 
in  the  industry.  Each  vendor  must  decide  the 
position  (i.e.,  rating)  and  type  of  products 
to  be  offered.  The  end  result  will  be  that 
all  products  will  contain  enriched  security 
mechanisms.  Vendor  wiLl  provide  standard 
products  which  meet  a  broad  spectrum  of 
security  and  processing  requirements. 

As  a  leader  in  the  class  B2  to  class  Al 
area  of  trusted  products,  Honeywell  has 
developed  a  basic  strategy  to  meet  the  needs 
of  this  market.  The  overall  strategy  in¬ 
cludes  the  coordination  of  security  related 
efforts  through  Honeywell.  A  high  level 
steering  group  reviews  plans  and  requirements 
to  ensure  that  the  technical  security  efforts 
are  directed  with  a  unified  goal  in  mind. 

This  group  meets  regularly  to  evaluate  product 
^harac Ler r s ti cs ,  program  results,  market 
requirements  and  research  directions.  The 
direction  provided  by  this  group  ensures  that 


the  efforts  of  various  organizations  are  all 
directed  to  meet  the  security  needs  of  the 
Honeywell  customers. 

Key  to  Honeywell's  effort  is  the  inclu¬ 
sion  of  enhanced  security  in  both  our  large 
and  small  commercial  product  bases.  Without 
basic  products  which  meet  the  evolving 
standards,  it  is  quite  unlikely  that  we  can 
provide  complete  solutions  to  the  high  end  of 
the  market.  Another  key  element  in  the 
strategy  is  to  ensure  that  research  is  pro¬ 
grammed  into  product  enhancements.  One 
example  of  this  is  the  inclusion  of  Scomp 
hardware  features  in  the  DPS6  PLUS  product, 
which  was  announced  in  June  this  year.  This 
commercial  hardware  platform  contains  the 
features  to  support  the  Scomp  capability. 

This  will  enable  the  evolution  of  enriched 
security  features  to  be  implemented  in  the 
commercial  operating  system  offering  as  well 
as  provide  a  new  platform  for  Scomp.  The 
Secure  Ada  Target  (SAT)  Program  is  also  being 
managed  such  that  this  technology  can  be 
planned  for  product  offerings  at  the  proper 
time . 

As  the  technology  evolves,  Honeywell  will 
insert  product  offerings  which  take  advantage 
of  proven  technology.  This  approach,  however, 
can  produce  some  difficult  challenges.  With 
each  new  innovation  comes  the  need  to  define 
the  security  impacts,  implementation  approach 
and  the  application  of  the  technology.  These 
are  the  challenges  that  make  the  trusted  sys¬ 
tem  market  interesting.  The  Scomp  system  was 
a  major  technical  accomp lishment  because  it 
demonstrated  the  ability  to  build  a  class  Al 
system.  The  challenge  now  is  to  build  a 
broad  product  offering,  meeting  high  level 
security  requirements  ana  providing  all  the 
features  available  in  the  non-trusted  market. 
To  understand  these  requirements  will  require 
a  quick  look  at  the  characteristics  of  this 
marketpl  aw  . 

MARKET  CHARACTERISTICS 

The  Honeywell  experience  witli  Scomp  and 
Multics  has  given  us  the  opportunity  to 
evaluate  a  variety  of  system  requirements . 
Because  these  systems  are  very  different  with 
respect  to  capacity,  performance  and  capabil¬ 
ity,  we  have  observed  requirements  across  a 
broad  spectrum.  This  experience  has  led  us 
to  the  definition  of  a  marketplace  model. 

This  model  looks  very  similar  to  many  system 
and  program  requirements.  It  is  not  much 
di i ferent  from  the  model  of  the  data  process¬ 
ing  industry  in  general.  Technology  has 
provided  the  capability  to  place  large  pro¬ 
cessing  capacity  at  user  locations  and  provide 
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effective  comrouni cations  between  these 
processing  elements. 

A  key  element  of  the  market,  which  is  not 
obvious  from  the  model,  is  the  need  for 
solutions  oriented  systems.  These  systems 
must  solve  the  users  problem  and  provide  the 
level  of  trust  necessary  for  the  user  environ¬ 
ment.  There  is  no  attempt  here  to  justify  the 
users  security  requirements.  Security  must  be 
an  element  of  the  specifications  just  as 
communications  interfaces  and  processing  re¬ 
quirements.  The  market  requires  systems 
which  solve  user  problems  and  protect  their 
processing  assets. 


To  establish  a  common  understanding  of 
these  elements,  it  is  necessary  to  describe 
some  of  their  features. 

Trusted  Work  Stations  -  The  requirement  for 
trusted  work  stations  is  quite  straight 
forward.  Users  desire  the  full  capability  of 
work  stations,  including  color  graphics, 
windowing,  disk  storage,  a  mouse  and  hard 
copy  capability.  Work  stations  run  a  variety 
of  software  including  MS-DOS*  and  UNIX.** 

The  challenge  is  to  provide  these  features, 
meet  the  security  requirements,  and  allow  all 
applications  software  to  run  without  modifi¬ 
cation  . 


The  Market  Model 

Figure  1  illustrates  the  interconnections 
of  several  classes  of  processing  elements. 

The  elements  are  interconnected  through  a 
Local  Area  Network  (I.AN)  .  There  are  efforts 
underway  by  several  vendors  to  produce  trusted 
LAN  products.  This  model  does  not  depend  on 
their  capability;  however,  these  products 
will  enhance  the  vendor's  ability  to  satisfy 
the  model  requirements.  The  LAN  is  required 
to  provide  efficient  control  between  the 
processing  elements.  The  elements  span  the 
spectrum  of  what  is  available  in  the  market 
today.  The  challenge  is  that  all  elements 
need  to  be  trusted  at  the  class  D2  to  class 
Al  leve 1 . 


Trusted  Servers  -  These  are  departmental 
size  systems  which  provide  a  broad  range  of 
processing  resources.  These  systems  manage 
the  data  resource  for  the  users.  This  data 
management  may  be  in  the  form  of  a  relational 
data  base  management  system,  document  manage¬ 
ment  system,  or  file  management  capability. 
This  system  manages  the  data  resource  for  the 
user,  and  enforces  the  security  policy. 


MS  is  a  trademark  of  Microsoft. 

UNIX  is  a  trademark  of  AT&T  Bell 
Laboratories . 


Ti  listed  Uystetn 


F i guru  1  . 


Maxket  Model . 


Trusted  Gateways  -  This  element  of  the  model 
provides  access  to  the  outside  v;orld.  This 
function  allows  users  to  access  information 
from  external  sources.  Many  requirements 
exist  to  protect  a  local  resource  (i.e.,  LAN) 
from  unauthorized  access.  The  Gateway  pro¬ 
vides  this  protection,  and  also  allows 
system  users  to  gain  access  to  other  non-local 
environments.  In  the  Government,  these 
gateways  will  require  TCP/IP  capabilities. 

In  the  commercial  world,  the  gateways  will 
probably  require  ISO  or  SNA  capabilities. 

Trusted  LAN  Access  -  The  development  of 
trusted  LANs  may  preclude  the  need  for  this 
element  of  the  model;  however,  the  functions 
are  still  required.  The  ; rusted  LAN  access 
element  will  ensure  the  separation  of  levels 
on  the  LAN,  and  provide  a  .rusted  interface 
to  the  LAN  mechanism.  The  concept  is  to 
provide  an  effective  user  interlace  lo  the 
LAN  . 

Standards  -  This  market  model  is  driven  by 
standards.  Everyone  involved  with  system 
requirements  is  quite  familiar  with  both 
official  standards  and  the  evolving  standards 
of  practice.  For  example,  there  are  several 
standards  for  LAN  connections.  Most  notably 
are  those  c,i  the  IEEE.  These  standards  are 
very  different  from  the  evolutionary  standards 
of  practice  such  as  UNIX  System  V  for  depart¬ 
mental  processing  and  UNIX  or  MS-DOS  for  work 
stations.  To  meet  the  requi rements  of  the 
market  model,  the  vendor  must:  ldont.il  the 
standards  to  be  supported  and  the  standards 
of  practice  which  will  be  supported. 

Application  -  One  of  the  major  lessons  learned 
with  the  Scomp  product  has  to  do  with  appli¬ 
cations  requirements.  Everyone  wants  Lo  see 
applications  running  which,  perform  functions 
Cor  the  user.  The  challenge  with  applications 
comes  from  several  sources. 

First,  there  are  commodity  applications 
which  users  would  like  to  use.  These  :nclude 
such  things  as  data  base  management ,  spread¬ 
sheet,  word  processing,  transaction  process¬ 
ing,  etc.  So  the  first  challenge  is  Lo  be 
able  to  support  a  variety  of  these  existing 
applications  in  the  trusted  environment. 

Second,  there  ate  many  applications  which 
require  a  security  model  which  Is  different: 
rrom  that  supported  by  the  basic  trusted 
ystom.  Examples  of  these  applications  in¬ 
clude  guards,  military  message  -.ystom  and  data 
base  management.  These  applications  require 
Lrustud  u lemcr. lc  which  cannot  just  oe  ported 
from  commodity  packages.  iiv  d.ulltngc  ir  to 
develop  effective  trusted  interlace:.-  which 
meet  a  wide  variety  of  market  roqui remen ts . 

And  finally,  there  arc  applications  which 
must,  oe  trusted  because  they  are  required  to 
handle  multi-level  objects.  At  example  of 
fit  is  kind  of  application  would  be  interfaces 
to  networks  that  contain  multiple  level 
traffic.  None  of  these  exist  today,  with  Die 
possible  exception  oL  AUTODIN.  To  meet  this 
challenge  will  require  appl 1  cat  ions  such  as 
trusted  TCP/IP  or  X.2B  capabilities. 


Solutions  -  To  meet  the  needs  of  the  market 
place  requires  a  strong  combination  of  pro¬ 
duct  and  integration  capabilities.  The 
products  will  provide  a  foundation  for  the 
building  of  system  solution.  The  vendor 
must,  be  committed  to  long  term  investment  to 
ring  the  technology  and  solutions  to  the 
customer.  To  meet  the  needs  of  the  market, 

The  vendor  will  have  to  combine  the  tradi¬ 
tional  vendor  role  with  the  system  integra¬ 
tion  role.  The  key  to  success  in  this  arena 
is  the  commitment  to  meeting  the  customer 
requirements .  These  solution  oriented 
systems  will  all  require  elements  ol  the 
model,  and  each  may  include  a  unique  piece 
that  is  only  an  emerging  technology.  A 
strong  technically  oriented  organization  will 
bo  the  most  successful  in  meeting  these 
solution  needs. 

THE  FIRST  STEP 

As  can  be  seen  from  this  quick  review  of 
the  trusted  marKet  requirements,  there  is  a 
great  deal  of  work  ahead.  There  are  also 
many  new  and  interesting  challenges  in  bring¬ 
ing  these  capabilities  to  the  market.  At 
Honeywell,  we  have  been  working  to  take  the 
initial  steps  to  begin  to  address  the  various 
elements  of  the  market  model.  Hy  no  means 
do  we  have  solut -ons  for  all  the  elements  or 
all  the  issues.  That,  is  the  challenge  to 
this  industry  over  the  next  several  decades. 

We  plan  on  building  on  the  technology  of 
the  Scomp  product,  by  producing  systems  which 
meet  the  requirements  of  the  model.  These 
systems  will  then  be  used  in  our  solution 
oriented  business  to  meet  customer  require¬ 
ments.  As  now  technology  is  advanced,  it  will 
also  be  integrated  into  solutions.  As  other 
vendors  provide  elements  necessary  to  meet 
our  users'  needs,  we  will  integrate  them  into 
sound  technical  solutions. 

Because  of  the  nature  oi  Scomp,  and  the 
type  of  system  it  provides,  our  initial  capa¬ 
bility  wall  be  in  the  departmental  sized 
system.  It  .is  well  known  that  Scomp  current¬ 
ly'  resides  on  a  if>  bit  mini-computer  hardware 
platform.  This  hardware  is  modified  to  meet 
the  needs  of  building  a  trusted  system. 

Several  years  ago  steps  were  taken  to  ensure 
that  t.tese  hardware  characteristics  would  be 
available  in  the  future  Honeywell  hardware 
platform.  This  was  accomplished  through 
close  working  relationships  between  the 
commercial  hardware  developers  and  the  Scomp 
development  'earn.  The  results  of  this  effort 
are  the  newly  announced  OPS  6  PLUS  product 
set.  This  commercial  product  provides  a  long 
term  technic? 1 1 v  advanced  b,  se  for  the  Scomp 
system.  Additionally,  the  hardware 

features  ensure  that  future  versions  of  l.h" 
commercial  operating  system  will  oe  able  to 
provide  enhanced  security  capabilities.  it 
is  now  planned  that  the  future  commercial 
operating  system  will  be  targeted  at  class  B2 . 

DPS  6  ri.us 

The  DPS 6  PLUS  is  a  new  generation  of  32- 
1.1  L  viitual  memory  coinput. urs.  It  is  built 
using  Very  Large  Scale  Integrated  (VI. SI) 
chips  as  integral  elements  of  the  central 
processor  and  the  memory  manager.  The  central 
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processor  firmware  ;s  loaded  via  t!u:  l ■  y . - 1  oin 
Man..'q  a  me  nt  Facility  to  jonln  J  :;ul  Ltfire 
cpc  tat.  ion . 

The  major  s  i  gnr  1  i  Cuie'  ot  the  DPSO  PLUS 
is  tha'  it  provides  ,-i  commercial  Hardware 
pir.  form,  without  Luc  need  for  special  hard¬ 
ware--  to  support  ho  S comp  Trus-ed  Operating 
'-'Oytam  (STOP),  The  in  i  t  i  a  1  i  z  .1 1  i  on  of  ..he 
system  will  be  achieved  through  the  firmware 
load  mechanism  ot  the  System  Management 
Facility.  Thin  K-ature  ot  the  DPS6  H.U5  will 
provide  a  groat  deal  of  flexibility  and  a  re¬ 
duction  in  product  cost.. 

injure  2  lists',  several  ol  the  toatures  of 
the  DPS  6  PLUS  end  the  Scomp .  As  car.  he  seoir, 
the  DPS  6  PLUS  provides  a  mul  1.  i -processor 
capability  wrth  a  large  virtual  address  per 
process.  The  perlormur. ec  of  the  system  tti 
enhanced  by  the  integration  of  the  Sc.i  on' i  1  ;  v 
and  Cc-mme  re  1  a  1  Instruction  Pi  wccs.-tor:; 
tC I  P/S  IP).  These  processors  were  not  avoid¬ 
able  on  the  16  bit  Scor.ip  Implementation. 
Additionally,  the  largest  segment  size  and  the 
availability  of  twice  as  many  segments  perfor¬ 
mance  . 

Because  of  the  firmware  load  capability, 
the  UPS 6  PLUS  implementation  of  3 comp  wi  If  be 
able  to  use  commercial  Test,  and  Verification 
(TSiV)  routines.  The  current  3 comp  requires  a 
unique  set  of  T&V’u  because  of  the  hardware 
differences.  This  will  be  a  major  cost  sav¬ 
ings  in  the  Dl’S6  PIUS  based  product. 

The  firmware  load  capability  is  also 
beneficial  u;  providing  the  mechanisms 
necessary  to  implement  the  one.  Scomp  feat  ut  _ 
not  in  the  DPS6  PLUS  hardware.  The 
commercial  DPS6  PLUS  only  provides  support  (or 
physical  Input/Output  ; 10) .  Firmware  will  be 
added  which  supports  the  virtual  10  capabili¬ 
ties  necessary  for  Scomp.  Because  of  tbit, 
difference,  only'  pro-mapped  IO  will  be  sup¬ 
ported  on  the  DPS6  PLUS.  The  mapped  to 
feature  ol  the  current  Scomp  will  not.  be 


ST0P_  3J) 

'The  first  version  of  the  Scomp  operating 
system  to  be  available  on  the  DPS6  PLUS  is  de¬ 
fined  as  STOP  3.0.  This  is  the  same  operating 
system  which  runs  cn  the  16  bit.  Scomp  except 
that  it  is  modified  to  support  the  features 
of  the  DP5L  PLUS.  Ti-tse  modifications  in¬ 
clude  t.he  larger  segment  •- ,  multiple:  process¬ 
ors,  new  10  capability,  and  new  ring  crossing 
me  cl  an isms .  The  user  interface  to  STOP  wild, 
remain  the  same,  and  the  application  inter 
Lace  to  the  system  will  bo  the  same. 

PluJ  t- pie  Processor  Suppor  t  -  The  16  bit  Scomp 
wan  .rr.plemented  01.  a  mono  processor  system. 

The  0P.S6  PLUS  supt  oj  i.s  single,  dual  and  quad 
processor  con  1  igut  at  ions  .  The  Scomp  Kernel 
is  being  redesigned  tn  effectively  support 
'no  multiple  processor  environment  .  This  is 
a  complex  enhancement  t.o  the  .Scomp  security 
Kernel,  a."  I  has  taken  the  most  effort  to 
dor.  ign  . 

bow  ltj  Support  -  The  current  Scomp  supports 
user  "Initial  ed  It)  capabilities.  This  will  no 
longer  be  true  on  the  DPS 6  PLUS  implementa¬ 
tion.  The  T0  capability'  wi  11  be  moved  into  a 
mere  privileged  ring  (ting  1),  and  the  system 
v,ill  perform  the  10  on  behalf  of  tho  user. 

This  change  is  required  because  of  the  follow- 
i  ng  . 

First,  the  10  environment,  on  the  DPS 6 
PLUS  is  quite  different  from  that  on  Scomp. 
There  is  nc  firmware  support  for  some  exist¬ 
ing  functions.  Secondly,  the  development  oi 
new  smart  device  coni  rollers  requires  the  10 
mechanism  t.o  be  protected  from  the  user 
environment . 
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AppI i cat  ion 

The  initial  application  to  be  supported 
in  the  D"86  PLUS  Scomp  will  bo  i  he  UNLPLKX  II* 
ntoqrated  office  application.  Tho  i implemen¬ 
tation  ol  UN1PI.EX  LI  is  current  Ly  being 
completed  on  the  lu-biu  Scomp  System.  UNIPLEX 
II  consists  of  word  processing,  fire  manage¬ 
ment,  data  base  management ,  spreas  sheet  and 
mail.  UNIPLEX  il  normally  runs  on  UNIX  based 
systems,  and  has  been  ported  to  Scomp  using 
our  evolving  C  sUndaru  application 
envi.  rorimen !  . 

livai ua t  ion  (loa  is 

The  l)PS6  PLUS  wi  th  STOP  1.0  will  be  bnilc 
in  accordance  with  the  class  A1  requi reman  ..s . 
The  system's  initial  evaluation  goai  will  be  a 
class  B.i  rating.  The  reason  Cor  this  is  that 
it  j educes  tho  risk  associated  with  verifi¬ 
cation.  There  are  many  issues  associated 
with  thi  3  product  enhancement  that  need  to  be 
addressed  t.n  the  verification  aspects  of  class 
nl.  An  example  ol.  this  is  multiple  processors 
and  smart,  controllers.  Additionally,  the 
technology  of  veri  fication  has  not  advanced 
significant  ly  from  the  current  Scomp  product, 
t.o  warrant  major  investment  in  this  technol¬ 
ogy  at  this  Lime.  Future  versions  of  STOP, 
however,  will  be  validated  at  the  class  Ai 
level  when  it  is  required  t.o  meet  the  market 
requirements.  Nothing  will  be  done  in  the 
development  of  STOP  3.U  which  would  preclude 
it.  t  ror  achieving  the  class  Al  rating. 

performance 

The  perf ormancc  range  of  the  DPS 6  PLUS 
■extends  the  performance  capability  of  the 
SCOMP  system.  There  will  be  additional  per 
formance  benefits  gained  from  the  larger 
segment  size  and  tho  integrated  S1P/C.CP  capa¬ 
bility.  Looking  at  the  per forniance  of  the 
DPS 6  PLUS  and  the  DPS6/75  produces  the 
following  results; 


o 

SCOMP 

(1)156/75) 

1 . 0 

o 

PS6  PLUS  1 

=  1  .  7 

o 

UPSG  1 

>LUS  ?. 

■=  3.2 

o 

UPSG  PLUS  4 

5  . 

These  per 1 ormancc  ratios  are  based  on  the 
basic  hardware,  and  have  not.  been  factored  to 
reflect  the  i jsspcic  t.  of  securlfv. 

THE  FUTURE 


App lie at i on  Knvir o n ment 

The  market  is  driving  the  departmental 
system  toward  the  UNIX  System  V  interface  as 
a  standard.  In  line  with  this,  the  STOP 
application  interface  is  being  enhanced  to 
make  the  porting  of  applications  from  UNIX  as 
easy  as  possible.  This  is  the  result  of 
several  efforts  to  port  UNIX  based  applica¬ 
tions  to  Scomp.  These  applications  include 
TCP/IP,  X. 25 ,  UN IP LEX  II  and  a  C- Compiler. 

This  is  not  an  effort  to  emulate  the  UNIX 
environment.  It  is  purely  a  mapping  of  UNIX 
interface  calls  to  services  provided  by  STOP. 
Our  approach  is  -O  provide  a  trusted  system 
which  supports  UNIX  applications.  Not.  all 
applications  will  port;  easily. 

Data  Base  Management  -  If  is  not  possible  to 
provide  true  MLS  relational  data  base  capa¬ 
bilities  today .  However,  the  use  of  a 
commercial  KD3MS  capability  on  a  trusted 
system  is  the  first  step  toward  realizing 
many  of  the  requirements  of  a  RDBMS  in  n 
trusted  environment.  Honeywell  plans  on  ad¬ 
dressing  this  need  by  providing  basic  data 
management  capabilities  on  future  versions  of 
Scomp.  The  approach  to  meet  this  requirement 
has  not  been  fully  defined.  Work  is  con¬ 
tinuing  in  several  areas  t.o  address  the  data 
base  management  requirements. 

Other  Products  -  The  DPS6  PLUS  Scomp  is  only 
one  element,  cl  the  market  model.  Efforts  are 
underway  at  Honeywell  tc  address  the  full 
spectrum  of  the  mciol  requirements.  These  are 
being  addressed  both  in  terms  of  product 
capabilities  and  as  evolving  research  issues. 
The  use  of  the  DPS6  PLUS  chip  set  is  being 
analyzed  with  respect  to  development  of  a 
micro  based  capability  which  could  meet  the 
needs  of  a  work  station  or  communications 
device.  These  efforts  are  in  their  early 
stages  and  should  produce  meaningful  results 
in  the  next  several  years. 

Additionally,  a  key  research  activity 
being  performed  by  the  Honeywell  Secure 
Computing  Technology  Center  (SCTC)  .is  being 
monitored  for  inclusion  in  product:  oriented 
solutions.  The  Secure  Ada  Target  (SAT) 
research  provides  a  potential  path  t.o  advanc¬ 
ed  security'  mechanisms.  The  timed  inclusion 
of  the  proven  technology  developed  by  SCTC 
will  be  a  key  element  in  the  development  of 
advanced  products. 


STOP  i.O  is  just  t.he  lirsl  of  a  planned 
evolution  of  systems  capability  on  the  DPS6 
PLUS  platform,  Additional  interlaces  and 
applications  will  be  developed  to  meet  tho 
needs  ot  the  market,  model.  These  efforts  will 
come  from  both  internal  and  project  directed 
funding.  Several  of  these  additions  are  being 
planned  at  this  time.  They  include  a  re¬ 
lational  data  base  management  capability',  DUH 
capaoiiii.y,  Ethernet*  i n*  °r  r tve  r.rv'  .’.'Hi '  i  era! 
support  tools . 

UNIPLEX  is  a  trademark  of  PedW'.o:  In!  .  Ltd. 
Ethernet  is  a  registered  trademark  ol 
Xerox  Corporal  i  or. . 
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*  * 


CONCLUSION 


This  paper  has  looked  at  the  requirements 
of  the  Trusted  System  market  place.  These 
requirements  cannot  all  be  met  with  existing 
product  platforms  and  capabilities.  This 
market  requires  a  strong  solution  oriented 
approach  combined  with  basic  platforms  to 
meet,  the  users  security  needs. 

Honeywell  has  come  a  long  way  in  achiev¬ 
ing  the  Scomp  and  Multics  evaluations.  These 
efforts,  however,  are  only  preliminary  to  our 
eventual  goal  of  providing  a  broad  range  of 
product  oriented  solutions.  The  DPS6  PLUS  is 
the  key  element  of  this  evolutionary  approach 
to  trusted  product  development.  The  DPSb 
PLUS ,  combined  with  standard  interfaces  and 
applications  environments,  will  provide  a  set 
of  quality  solutions  tor  systems  users. 
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ABSTRACT 


Since  the  late  seventies,  Digital 

Equipment  Corporation  has  been  pursuing  a 
development  program  aimed  at  improving  the 
security  of  its  computer  system  and  network 
products.  The  most  visible  product  of  this 
program  to  date  has  been  Version  4.2  of  the 
VAX/VMS  operating  system,  which  is  under 
evaluation  as  a  candidate  for  Class  C2  of  the 
Trusted  Computer  System  Evaluation  Criteria. 
In  addition  to  implementing  discretionary 

VAX/VMS  Version  4.2 
support  for  mandatory 
the  level  of  internal 
routines  and  data 
paper  describes  SE/VMS 
VMS) ,  a  set  of 


access  controls, 
incorporates  latent 
security  controls  at 
operating  system 

structures.  This 
(Security  Enhanced 

modifications  that  allow  VAX/VMS  users  to 
exploit  the  latent  support  for  mandatory 
se>  rity.  The  modifications  provide 

fac  ities  that  allow  a  system  manager  to  set 
up  and  administer  the  mandatory  security 
environment,  and  that  allow  users  to  operate 
on  labeled  objects.  The  paper  describes  the 
SE/VMS  that  support  user 
login,  device  and  volume 
creation  and  access,  and  the 
labeled  printed  output, 
provided  of  the  techniques 
implement  SE/VMS,  of  the 
system's  limitations,  and  of  plans  to  gain 
user  experience  with  SE/VMS.  SE/VMS  is 
viewed  as  providing  an  interim  mandatory 
security  capability  for  VAX/VMS  users,  and 
will  not  be  submitted  for  evaluation  at  Class 
B1  of  the  Criteria. 


functions  of 
reg is t rat  ion  and 
management,  file 
production  of 
Discussions  are 
that  were  used  to 


1  INTRODUCTION 


labeled  security  protection  for  VAX/VMS. 
This  work  is  intended  to  meet  most  of  the 
requirements  for  Class  B1  of  the  TCSEC. 
Because  SE/VMS  does  not  meet  all  requirements 
and  is  intended  to  provide  only  an  interim 
capability,  it  would  not  be  a  candidate  for 
submission  for  formal  product  evaluation  at 
Class  Bl. 

SE/VMS  is  not  an  "add-on"  security 
package  in  the  sense  of  some  of  the  products 
on  the  National  Computer  Security  Center's 
Evaluated  Products  List.  Instead  it  combines 
latent  capabilities  of  VAX/VMS,  replacements 
for  some  VAX/VMS  components,  and  additional 
components  to  achieve  the  overall  objective 
of  providing  labeled  protection. 

This  paper  begins  with  a  review  of  the 
security  features  of  VAX/VMS  Version  4.2.  It 
then  summarizes  the  support  for  mandatory 
security  that  was  included  in  Version  4.2. 
Next,  the  paper  presents  an  overview  of  the 
features  of  SE/VMS  along  with  a  sketch  of  the 
techniques  tnat  were  used  to  implement  them. 
Finally,  we  conclude  with  a  discussion  of 
areas  for  future  development  in  providing 
mandatory  security  for  VAX/VMS. 


2  SECURITY  IN  VAX/VMS 

VAX/VMS  was  initially  developed  in  the 
mid  seventies  along  with  the  VAX-11/780 
3?-bit  superminicomputer.  The  VAX-1  1/700  was 
developed  as  an  upward-compatible  extension 
to  the  PDP-11  minicomputer  family  and 
executes  PDP-11  code  directly.  As  the  VAX 
family  grew  out  of  the  PDP-11,  so  VAX/VMS 
grew  out  of  the  RSX-ll/M  operating  system  for 
the  PDP-11. 


Since  the  late  seventies.  Digital 
Equipment  Corporation  has  been  pursuing  an 
active  development  program  aimed  at  improving 
the  security  of  our  computer  system  and 
network  products.  The  primary  focus  of  this 
program  has  been  a  series  of  enhancements  to 
the  secur.ty  of  the  VAX/VHS  operating  system. 
The  most  visible  product  of  the  program  to 
date  has  been  VAX/VMS  Version  4.2,  which  has 
been  submitted  Cor  evaluation  at  Class  C2  of 
the  Trusted  Computer  System  Evaluation 
Criteria1  (TCSEC) . 

This  paper  describes  SE/VMS  (Security 
Enhanced  VMS) ,  modifications  that  have  been 
developed  to  provide  an  initial  mandatory 
security  capability  for  VAX/VMS.  These 
modifications  were  developed  by  Digital's 
Software  Services  organization  to  provide 


Initial  releases  of 
ncluded  a  significant 
tility  programs  that 
nmodified  from  RSX. 

AX/VMS  security  design 
n  i  n icompu te r "  model 

asswords  at 

sys tem/owner/g roup/ world" 
lies,  directories  and  a 
AX/VMS  has  always 
ncryption  of  user  passwords,  and  over  the 
ears  a  number  of  security  auditing  functions 
ere  incorporated  with  the  system's 

r’cmmh  i  nrl  f  o.lfn  TPQ  . 


VAX/VMS  actually 
number  of  PDP-11 
were  transported 
Thus  the  initial 
was  an  extended 
and  encompassed 
login  and 

pro  tect  ion  on 
few  other  objects, 
supported  one-way 


In  the  late 
e ight ies  ,  a  ma  jor 
the  aim  of  upgrading 
The  first  product  of 


seventies  and  early 
project  was  started  with 
the  security  of  VAX/VMS. 
this  project  was  VAX/'/MS 
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Version  4.0,  and  some  additional  enhancements 
were  incorporated  in  Version  4.2.  When  this 
paper  discusses  the  features  of  SIC/VMS,  it 
describes  changes  or  enhancements  to 

Version  4.2.  "“cause  the  initial 

implementation  oi  mandatory  controls  was 
incorporated  in  Version  4.0,  the  paragraphs 
below  will  refer  to  Version  4.0  in  some 
cases.  (Odd-numbered  versions  since  4.0  have 
been  dedicated  to  "bug  fixes"  rather  than 
significant  reature  enhancements.)  As  it 

currently  exists,  VAX/VMS  Version  4.2 
incorporates  the  following  security 

enhancements  : 

o  A  number  of  "account  management” 

features  including  account  expiration, 
restrictions  on  days  and  times  of 
login,  and  restrictions  on  access  to 
accounts  (no  dialup,  no  network, 

etc . )  . 

o  A  number  of  passwoid  management 
features  including  required  change  of. 
initial  passwords  for  privileged 

accounts,  password  expiration, 
minimum  password  length, 

dual-password  accounts,  and  a  random 
pronounceable  password  generator. 

o  Features  directed  toward  systems 
that  support  dialup  lines  or 
networks  including  automatic  hangup 
and  limits  on  unsuccessful  login 
attempts  directed  to  an  account. 

o  Access  control  list  and  identifier 
features  allow  the  system  manager  to 
define  arbitrary  groups  of  users, 
and  allow  users  to  grant  or  deny 
access  to  files  by  individual  users  or 
defined  groups. 

o  Selective  security  auditing  features 
produce  an  audit  trial  of  successful 
and/or  failed  attempts  at  such 
operations  as  user  login,  access  to 
files,  and  use  of  certain 
privileges.  The  audit  trail  is 
directed  both  to  a  terminal  ana  a 
log  file,  and  can  bo  analyzed  by  a 
reduction  procedure  included  in  the 
system . 

o  Features  introduced  in  VAX/VMS 
Version  4.0  prevent  "disk 

scavenging"  by  insuring  that  disk 
files  are  erased  on  deletion,  or 
that  blocks  newly  allocated  to  1 i I  "s 
are  pre  -erased ,  VAX/VMS  systems 
have  always  erased  primary  memory 
pages  before  making  them  addressable  to 
a  process,  so  the  enhancement  to  disk 
storage  allocation  eliminates  the  last 
possibility  for  disclosure  of 

information  by  object  reuse. 

o  A  “ secure  server"  key  prevents  users 
from  implementing  "password 

grabbers"  by  guaranteeing  that  a 
user  of  a  hardwired  terminal  who 
presses  the  break  key  will  always 
receive  a  login  prompt  from  the 
operating  system.  Equivalent 

feature.',  are  provided  for  users 
whose  terminals  are  attached  to 
terminal  concentrators  or  VAX 

network  hosts. 

o  A  “(in  i  d,e  to  VAX/VES  .System 

Security”  was  developed  along  with 
VAX/VMb  Version  4.0,  and  updated 


for  Version  4.2.  The  guide  provides 
detailed  information  fur  both  users 
and  system  managers. 

The  development  of  VAX/VMS  Version  4.0 
was  started  before  the  completion  of  the 
final  version  of  the  TCSF.C.  Nonetheless,  the 
developers  were  aware  of  the  Criteria 
development  process,  and  tracked  the  content 
of  each  draft  of  the  TCSEC.  A  specific  goal 
of  VAX/VMS  Version  4.2  was  that  it  meet  the 
requirements  of  Class  C2,  Controlled  Access 
Protection.  VAX/VMS  Version  4.2  has  been 
under  formal  evaluation  as  a  candidate  for 
Class  C2  since  late  1985. 


3  MANDATORY  CONTROLS  FOR  VAX/VMS 

While  the  primary  security  evaluation 
goal  for  VAX/VMS  Version  4.0  was  to  meet  the 
requirements  of  Class  C2  of  the  TCSEC,  it  was 
understood  during  the  development  process 
that  incorporation  of  mandatory  security 
controls  was  both  a  feasible  and  desirable 
objective.  Resource  limitations  and 

time-to-market  constraints  prevented  the 
completion  of  the  mandatory  security 
features.  However,  a  good  deal  of  work  was 
completed,  and  "latent  support”  for  mandatory 
security  ,w;  been  present  in  every  release  of 
VAX/VMS  since  Version  4.0. 

Early  in  the  development  of,  VAX/VMS 
Version  4.0..  a  decision  was  made  that  the 
system  would  support  ^both  the  lattice 
security  and  integrity  models,  with  fields 
allocated  to  support  256  levels  and  64 
categories  toi  each  of  the  security  and 
integrity  models.  The  tields  were  encoded  in 
a  conventional  way  -  a  byte  each  for  security 
and  integrity  levels,  and  a  6 4 -bit  quad word 
for  security  and  integrity  category  masks. 
These  fields,  plus  an  additional  16-bit  word 
used  as  a  filler,  form  a  five  longword 
structure  known  as  an  "access  classification 
block",  or  CLS  block.  Thus,  the  total 
storage  required  to  represent  a  security 
"access  class"  (levels  and  categories  for 
security  and  integrity)  is  100  bits.  As  part 
of  the  development  of  VAX/VMS  Version  4.0, 
CLS  blocks  were  added  to  the  data  structures 
Cor  the  system's  subjects  and  objects. 

The  security  properties  of  a  subject  are 
recorded  in  a  CLS  block  within  an  "Agent's 
Rights  Block",  or  ARB,  that  includes  the 
subject's  current  access  class  as  well  as 
identity,  group  and  privilege  information 
that  is  used  for  the  other  protection  checks 
performed  by  Version  4.0.  The  only  subjects 
on  a  VMS  system  are  processes. 

The  security  properties  of  most  objects 
(files.  "mailboxes",  logical  name  tables, 
devices,  and  global  sections)  that  are  active 
(accessible  or  “opened")  in  the  system  are 
stored  in  "Object's  Rights  Blocks"  or  ORBs . 
An  ORB  coni ains  two  CLS  blocks,  specifying 
minimum  and  maximum  access  classes  fur  the 
object,  as  well  as  discretionary  access 
control  information.  Other  objects  (e.g. 
mounted  disk  volumes)  have  Cl.B  blocks  as  part 
of  their  control  structure.  While  the  major 


storage  objects  arc  labeled  with  CLS  blocks, 
a  few  (less  critical)  interprocess 

communication  objects  are  not  labeled. 

The  ORB  and  ARB  are  data  structures  that 
apply  to  active  subjects  and  objects  in  a 
VAX/ VMS  system  --  processes  that  are  logged 
in  (ARB) ,  and  open  files,  logical  name 
tables,  and  so  on  (ORR's).  For  mandatory 
security  controls  to  he  effective  l hey  must 
also,  of  course,  apply  lo  permanent  subjects 
and  objects  -•  registered  users,  files, 
directories  and  volumes.  Thus  the  system's 
permanent  data  structures  were  enhanced  to 
record  access  class  information.  The  User 
Authorization  File  (UAF)  entry  for  a  user 
records  that  user's  minimum  and  maximum 
access  class.  The  "volume  home  block"  for  a 
ili.sk  volume  records  the  minimum  and  maximum 
access  class  for  the  volume,  while  the  “file 
header"  for  each  tile  records  the  tile's 
access  class.  In  all  cases  the  standard 
VAX/VMS  160-bit.  CLS  block  is  used  Lo  store 
the  a c  c  ess  class. 


Volumes  and  devices  may  he  mu  1 
(minimum  and  maximum  access  '  1  ass  may 
for  each  object,  as  sol  i.y  i  he 
manager)  while  a  file  always  has  a 
access  class.  Directories  are  file 
special  propfi rt i es  and  also  have  a 


mu  1  t:  i  l  eve  t 
sb  may  <1 1 1  fe r 
i he  system 
has  a  single 
files?  with 
have  <>  si  ng  l  <* 


access  class.  Additional  process  trout  to I  and 
communication  objects  (i.o.  logical  name 

tali' e:;,  global  sections,  "ina  i  1  boxer." )  are 
potentially  multilevel  objects. 

Tn  -Id  it  ion  to  .Hiding  access  class 
information  lor  .subjects  and  objocis,  the 
VAX/VMfl  Version  4 .  ft  development  project  also 
completed  the  code  required  to  implement 

mandatory  controls  for  files,  and  extended 
the  executive's  central  protection  checking 
routine  to  ref  led.  the  access  class  ol 
subject  and  object  in  its  decision  to  grant 
or  deny  access.  Access  checks  and 

propagation  of  access  classes;  were  based 
directly  on  the  r  roqu  i  remen  t.s  ol  the 
Be  1  l  -  F.a  Pad  u  1  a  model5.  A  subject,  may  only 
read  an  object  it  the  subject’s  access  class 
dominates  the  object':;  access  class  (simple 
security  condition)  .  A  .subject  may  only 
write  an  object  il  the  object's  access  class 
dominates  the  subject's  access  class 
(‘-property  or  cunt  incr.ent  property). 


While  1  hr'  cod e  t  'a a  r 
part  of  VAX/VMS  Version 


made  to  allow 


sub  j  eel; 
CM:  1  y  l  rt 


a  subject's  access  eta 
objects  i t  e rented 
Be  1  1  -I, a  Pa  tin  1  a  model's  rul 
ob  jects.  Thus,  I  here 
a b  i  1  l I y  to  l a bo  1  objects, 


checks  access  was. 
4.H,  no  provis.  ion  was, 
to  have  a  non-. zero 
the  case  oi  ( i ! " s  was 
ass.  propagated  to 
as  roqu t  r ed  by  l he 
1  es,  lor  ci  ea t  ion  of 
was,  no  ope :  at  i c na  1 
,  only  a  l a l  on  t  one . 


is  Zero,  access  i s 
n s.  i  who  sets 

i nadvo r tent  1 y  will 
to  access  che.-k".  lm 
" broken" . 


A  pair  of  privileges  --  downgrade  ami 
upgrade  ■  may  be  granted  lo  a  process  to 
exempt  it.  from  I  lie  security  and  inlegrily 
*  pro  pe  r  t  i  os  respectively.  The  oxeeul  ion  ol 
the  mandatory  security  access,  check  in 
VAX/VM.'  Version  4 .  V-  is  corn!  i  l  i  omul  on  a 
global  "sysgen"  parameter:  when  1  he 

parameter  i  ■;  1,  checking  is.  enabled.  Tin* 

Sense  111  I  hr*  encoding  of  access  classes  is 
such  1  h  1 1  ,  as.  long  as  I  he  en  I  i  r  ■*  access,  class 


ways  n ranted.  Thus  a 
ill-  sysgen  parameter 
■■■<■  son  e  pi  ouessot  time 
wiLl  lee  1  i’id  his  system 


The  implementation  ol  mandatory  controls 
in  VAX/VMB  Version  4 .  H  provides  a  relatively 
complete  set  of  si  ■  m- 1  n  i  es  and  support,  in  the 
operating  system  kr-incl  lor  labeled  security 
protection.  However  ,  no  user  (or  system 
manager)  interface  '  •  ■  i  he  m  in  l.itory  access 
controls  is  provided,  i  •  t -  class  is  only 
propagated  for  file..,  and  mandatory  access 
checks  are  not.  made  during  some  operations 
(e.g.  mounting  disks).  in  addition,  even 
though  file  access  failures  caused  by  a 
violation  of.  mandatory  security  will  appear 
in  the  system's  audit  tiail,  the  reason  Cor 
such  failures  (i.e.  tin*  incompatible  access 
c  l  asses)  will  not  . 


If  an  installation  ' 
mandatory  security  sup 
must  have  a  way  to  assoc 
names  with  levels  and 
"clearances"  to  users, 
select  an  access  cl  as 
display  access  class  inf 
output  ,  in  directory  l is 
addition,  a  system 
1  tic  i  1  1 1  i  es  t.o  se  I  up 
defining  the  access,  el  as 
volumes,  and  terminals, 
t.o  access  c  1  ass  -  r  e  l  a  t;  od 
syst cm' s  aud  i  t  trail. 


:?  to  make  use  of  the 
port  in  VAX/VMfl,  it 
:  l  a  I. u  c  ha  r  uc  to  r-  s  t.  r  i  ng 
categories,  to  assign 
to  allow  users  to 
s  at  login,  and  t.o 
urination  on  printed 
t  itigs,  and  so  on.  In 
manager  must  have 
a  system,  lor  example 
s  range::  of  drives, 
and  must  have  access 
information  it:  the 


A  number  ol  Digital's  users  have 
"discovered"  the  mandatory  security  features 
in  VAX/VMfl  niiCjl  written  the  i  r  own  software  to 
exploit  them’.  The  experience  of.  these 
users  seems  to  show  both  the  viability  ot  the 
implementation  ol  mandatory  security  controls 
in  VAX/VMB  Version  4.?.  and  the  critical  need 
ol  suin'*  users  for  these  features. 


4  .'IL'PI’ORTlNtl  MANDATORY  fill  CUR  TTY  IN  VAX/VMB 

This  section  describe!;  the  feature:;  and 
implementation  ol  SK/'.'MS.  In  the  I  ol  lowing 
paragraphs,  emphasis  has  boon  placed  on  the 
! IK/ VMS  I  eat. ures  t  hat  support  mandatory 
security  controls.  As  was  ineiit  i  otieil  above, 
integrity  labeling  is  also  present  and 
supported  in  SK/VMS,  but  most  mention  ol  Hie 
integrity  model  has  boon  omitted  Irwin  the 
paragraphs  below  in  an  at: tempt  to  shorten  and 
simplify  tlie  presentation. 


4  .  !  Ob j  ect  i Vos 

The  rt :  sen:;:;  i  on  above  has  described  the 
■aippoi  t  for  in  lndatnr  y  security  controls  that 
is  present,  in  VAX/VMS  Version  4./,  as  wo  1  l  as 
l  he  supper  l  'h.ai  ha.s  not  yet  been  comp  let  od  , 
The  object  ive  ol  the  SK/VMS  d eve  1  upmou l.  was 
lo  provide  near-term  support  lor  mandatory 
security.  Tin  ground  rule  .il  the  development 
el  foil  was  I u  provide  a  complete  and  usable 
system,  bul  i  -  defer  wliru  e  noeess  ,i  r  y  support 
lor  I  i*,ii  hi  i"i  or  facilities  that  would  mid u  1  y 


lli 

P 


I 


complicate  or  delay  ihc  provision  of  basic 
support  .  Specif  lc.illy,  it  was  decided  not  t  <.j 


modify  any  o  f  the  exist  imj  :'.yst  i.mii  cl.it  a 
structures.  N  i  i1!  lot  t  was  made  to  add 


mandatory'  controls  t  u  any  object  that  did  not 
already  have  a  CLS  block  in  i  t  s  .uukh:  )  a t  ed 
dat  a  s t  r  tic  t  n i  os  . 


4  .  2  Appr  ouch 

Tilt'  technical  approach  to  l  lit* 

dove  b)  pinent  of  SK/VMS  was,  as  might  be 
expected,  to  build  on  tin*  support.  lot 
mandatory  security  in  VAX/VMS  Version  4.2, 
and  to  add  those  component.';  that  we  i  e  missing 
or  incomplete  in  Vers,  ion  4.2.  In  pract  ice , 
this*  etlort  requirt'd  a  few  changes  to  the 
basic  Vims,  ion  4.2  executive,  the  r  op  l  aeei.ion  t 
of  some  Version  4.2  modules  with  enhanced 
ones,  and  the  deve  lopment  of  some  entirely 
new  module.1', .  because  the  VMS  d  eve )  o{imen  t 
qroup  enhanced  the  latent  support  for 
mandatory  security  th.it  had  t»een  pi  esent  in 
Version  4.2  by  addin-)  system  set  vice  rout  ines 
to  the  exeeut  tve  f  « ,  r  VAX/VMS  Version  4.4,  11 

was  then  uerlded  that  SF/VMS  would  he 
developed  as  a  s»*l  of  enhancements  f  o  Version 
4.4. 

The  followin')  sect  ions  describe  the 
features  that  were  added  by  SK/VMh  and  the 
general  appr  ouches  to  imp  l  einetit  i  ng  those 
features.  An  overview  of  the  implementation 
oL  KK/VMS  is  pr  o  v  i  tied  at  the  end  of  I  hi:; 
sec t ion  . 


4 .  .1  Names  Pot  Access  (Masses 

VAX/VMS  Hiori’S  an  access  class  (in  a  (U.S 
block)  .is  a  purely  numeric  value.  Therefore 
«i  mapping  between  the  alphanumeric  name  of  a 
security  ot  integrity  level  <>i  catogoiy  and 
the  corresponding  encoded  value  is  needed 
both  for  input  (uset  r  eg  i I  r  a  f  i  on  ,  login, 
etc.)  and  out  put  (direct  oiy  listing,  printed 
out  put  )  . 

The  VAX/VM. *i  r  ighls  database  supports 
mapping  hot  wi.mmi  numeric:  values  and 

a  1  piianiiine  r  i  c  i  dent  If  iers  (name.;)  as,  part  of 
the  use  r  group  ident  if  ier  median  i  sin  menl  loned 
above.  A  range  of  binary  ident  if  ier  values, 
was  reserved  to  liold  the*  name*.*;  of  security 
and  integrity  love].1  and  categories,  A 
simple  arithmetic  conversion  allows  tin:  VMS 
executive  to  transform  the  value 

corresponding  to  a  level  or  the  bit  posit  ion 
corresponding  to  a  category  into  a  binary 
identifier  value.  Pre-existing  median  i  cans 
tor  processing  the  rights  database  implement 
the*  mapping  bet  ween  identifier  value  and 
alphanumeric  name.  VAX/VM:',  already  provide?; 
a  utility  to  in  a  1  nt  a  i  n  the  lights  dal  abase  ,  as 
we  l  1  as  t  lu.'  User  Aul  hot  1  z-U  ion  file 
(  An  *  ho  r  i  /.<  * }  ;  commands  were  added  to  this 
utility  that  allow  the  syst  cm  manager  I  o 
Specify  tlie  names  of  security  and  integrity 
1  e  ve  l  s  find  categories. 


4.4  Sy s t  ('in  Service  Support 

A  uniform  syntax  war,  developed  for  Lhe 
specification  of  access  classes  by  users 
(Figure  1).  This  syntax  allowed  Lor  the 
specification  -.1  classification  information 
by  an  alphanumeric  string  (as  described 
above)  ,  or  by  numeric  value.  The  VMS 
development  group  provided  two  new  system 
services  in  Vers; ion  4.4,  one  to  parse  ASCII 
ac:ce:;s  class  strings  find  translate  them  Into 
binary  d.S  block*;  and  a  second  to  create  an 
ASCII  access  class  string  from  a  CLS 
block. 

( LKVKL  SKCRKT) 

(CATKbORY  ■  27  ) 

(LKVKL  TOP  SKCKKT, 

CAT KCiORY  (  H  LIJ  K  ,  RKD)  ) 

{  LKVKl.  (MIN  I  MUM  :  SKCRkIT, 

MAX  IMUM  :Tt)l’  SKCRKT) ,  CAT  KCIORY  UKD) 

(  LKVKl.  (MINIMUM  :  UNCLASS  l  F  I  Kb, 

MAX  1  MUM  :  2h S )  ,  CATKC.OR  IKS  (1,1)) 


Figure  1.  Kx  iimp  l  <*s  of  V.ilid  Access  Class 
St  r  i ng  s 


A  third  :;y:;t  em  service  w.is  provided  to  set 
and  get  tin*  access  classes  ot  those  objects 
that  have  associated  ORHs .  The.se  are  the 
services  that  became  available  with  VAX/VMS 
Version  4.4,  and  motivated  the  decision  to 
implement  SK/VMK  under  that  version  rather 
t  han  Vi?  i  i  on  4.2. 


4,')  Authorizing  Users 

The  system  manager  who  wishes  to  add  a 
user  t  o  an  SK/VMS  system  must  be  able  to 
specify  a  “clearance"  for  that  user.  The 
VAX/vms  Authorize  utility  is  normally  used  to 
register  usei  s  and  specify  their  security 
attributes.  Authorize  was  modi  lied  lor 

SK/VM:’-  to  accept.  user  access  class 
informal  ion.  A  syntax  for  entering  such 
informal  ion  war;  devised  that  is  consistent, 
with  normal  usage  in  VAX/VM.S  and  Authorize 
(Figure  2).  because  VAX/VMS.  already  uses  tin* 
" /KFCIIR  1TY "  command  qua  I  if  i  <?  r  for  other 
purposes,  " /!> IICRKCY "  is  used  to  specify  the 
mandatory  security  clearance  piopei'ty. 

UAF>AIM)  MCJDKKN/KKCRKCY 

(LKVKL  :  (MIN  IMUM:  UNCI. AS.' 1 1  FI  Kb, 

MAX  l  MUM  ;T()P  li KCRKT)  , 

CAT Kt  JURY :  (MAXIMUM:  { A PPLH , BANANA) )  ) 
Figure  2.  Specifying  User  Clearance 

A  user  can  lu*  allowed  a  single 
e  !  as  s  l  f  i  ca  t  i  on  r  <>t  a  range  of 

i :  1 .  i  s  s  l  I  ic.it  ions. 


4  .  (i  Logg  i  ng  I  n 

Tin-  VAX/VM:;  l.Oi;  I  NODT  Utility  was 
mod  i  f  led  l»,  assign  an  I'i'.'i:;  class  to  the 
user1:;  process,  and  l  o  v  a  1  i  d a  I  e  I  1 1 a  t  access 
el. is:;.  When  a  u:a*i  logs  in  inteiaci  ivdy,  an 


access  class  for  his  or  her  process  can  be 
specified  using  the  standard  syntax  (Figure 
3).  If  none  is  specified,  the  process  will 
default  to  the  user's  maximum  authorized 
access  class. 

USERNAME:  L I PNER/EEC= ( L EVE L : S ECRET , 
CATEGOliY  :  i  BANANA , GRAPE )  ) 


Figure  3.  Login  With  Classification  Specified 

The  LOGINOUT  utility  then  validates  th„L 
the  access  class  is  between  the  user's 
minimum  and  maximum  (as  well  as  validating 
the  login  against  the  other  information  in 
the  UAF)  .  It  also  validates  the  requested 
access  class  for  the  login  against  the  range 
of  access  classes  authorized  for  the  terminal 
(See  below) .  LOGINOUT  then  stores  the  access 
class  in  the  process’  ARB.  In  the  case  of  a 
non-interactive  login,  such  as  a  submitted 
batch  job,  the  process  is  assigned  the  user's 
maximum  access  class  and  validation  is 
performed  against  the  command,  error  and  log 
files  specified  by  the  user. 


4.7  Volumes  And  Devices 

The  system  manager  of  a  SE/VMS  system 
will  notmally  wish  to  specify  the  ranges  of 
access  classes  for  mass  storage  devices  and 
volumes  and  for  user  terminals.  A  new 
command  and  associated  utility  program  allow 
the  system  manager  to  specify  the  necessary 
parameters  for  objects  with  ORBs  (Figure  4). 

SET  C LAS S/OB JECT_TYPE=DEV1C£/SECRECY= 
(LEVEL: (MINIMUM : SECRET, 

MAXIMUM :TOP_SECRET)  , 

CATEGORY: (MAXIMUM: (APPLE , BANANA) ) ) 
DUA1 : 

Figure  4.  Setting  Device  Access  Class. 

New  switches  (/SECRECY  and  /INTEGRITY) 


have  been 

add< 

1  to 

the 

INITIALIZE  command 

(Figure  5) 

to 

allow 

a 

volume 

to 

be 

initialized 

so 

that 

only 

files 

within 

a 

specified  range 

of  access 

c lasses 

can 

be 

written  to  it.  The  INITIALIZE  command 
operates  on  a  disk  volume  that  is  physically 
mounted  on  the  VAX  system  but  not  yet 
logically  accessible  to  application  programs. 
The  access  class  is  stored  in  the  home  block 
of  the  disk. 


INITIALIZE/ SECRECY= (LEVEL: ( M I N IM UM : SECRET , 
MAXIMUM : TOP_SECRET) )  USERDISK02 

Figure  9.  Setting  Volume  Access  Class. 

The  SE'l  CLASS  commands  may  only  be  used 
by  the  system  manager  or  a  privileged  user  to 
change  the  c lass i f i cat i on  of  objects  owned  by 
the  system.  Their  effect  is  to  set  the 
minimum  and  maximum  access  class  values  in 
the  ORB  for  the  specified  object.  Because 
the  ORB  is  a  transitory  data  structure,  these 
commands  must  be  repeated  each  time  the 
system  is  rebooted.  They  will  normally  be 


included  in  a  command  procedure  that  is 
executed  at  system  startup  time  before  users 
may  log  in.  This  use  of  a  command  procedure 
is  consistent  with  normal  VAX/VMS  practice. 

When  files  on  a  volume  are  to  be  made 
accessible  to  SE/VMS  users  and  programs,  an 
option  of  the  the  SE/VMS  MOUNT  command 
compares  the  access  class  ranges  of  device 
and  volume  and,  if  the  range  of  the  volume  is 
"within"  that  for  the  device,  allows  the 
mount  to  proceed.  In  this  case,  the  MOUNT 
command  copies  the  access  class  range  for  the 
volume  into  the  device's  ORB,  saving  the  old 
device  access  class  information  so  that  it 
may  be  restored  when  the  volume  is 
dismounted.  The  MOUNT  and  SET  CLASS  commands 
allow  the  system  manager  to  mount  a  foreign 
disk  or  tape  volume  at  the  access  class  of 
the  device  where  the  volume  is  to  be  mounted. 


4.8  Operations  On  Files  And  Directories 

As  was  mentioned  In  the  discussion  of 
mandatory  controls  in  Version  4.0,  the 
operations  of  object  creation  and  initial 
access  (file  open)  built  into  VAX/VMS 
implement  the  requirements  of  the 
Be  1 1-La Padul a  model  in  a  straightforward 
fashion.  A  newly  created  file  or  directory 
inherits  the  access  class  of  the  creating 
process.  Opens  for  reading  and  writing  are 
subject  to  the  constraints  of  the  simple 
security  condition  and  "-property. 

As  with  any  system  that  implements  the 
lattice  model  and  a  hierarchical  file  system, 
SE/VMS  enforces  a  "compatible"  hierarchy  in 
which  the  security  classes  of  files  and 
directories  are  monotoni cally  non-decreasing 
(and  integrity  classes  non- i nc r eas i ng)  as  one 
proceeds  away  from  a  volume’s  root  directory. 
Any  user  can  create  an  "upgraded" 
directory  via  the  SET  CLASS  command,  but  will 
then  be  unable  to  gain  access  to  the  new 
directory  without  logging  in  at  a  higher 
access  class.  The  files  within  a  given 
directory  will  normally  be  at  a  uniform 
access  class  and  only  directories  will  be 
upg  raded  . 

Any  user  who  owns  or  uses  files  at 
multiple  access  cl  sses  will  require  a  way  to 
discover  what  f  es  and  directories  are 
present:  at  various  access  classes.  The  VMS 
DIRECTORY/FULL  and  DI RECTOR Y/SECURI TY 
commands  (requiring  read  access  to  the 
directory)  have  been  modified  for  SE/VMS  to 
produce  a  listing  of  file  and  directory  names 
and  access  classes  for  user  review. 

The  VAX/VMS  BACKUP  utility  was  modified 
to  preserve  the  classifications  of  files  and 
directories  when  they  are  backed  up  to  tape 
or  disk.  Access  checks  are  made  during  both 
backup  and  restore  operations. 


•1.9  Additional  Objects 

Because  of  the  structure  of  VAX/VMS,  any 
object  that  has  an  associated  GRb  will  be 
protected  by  the  system's  mandatory  control:'. 


Logical  name  tables  (used  to  translate  names 
used  by  programs  and  the  VAX/VMS  command 
language) ,  global  sections  (used  to  map  files 
into  shareable  areas  of  main  memory),  and 
"mailboxes"  (used  for  interprocess 
communication  like  Unix(tm)  pipes)  have 
associated  ORB's  and  thus  are  protected  by 
the  system's  mandatory  controls. 

These  additional  objects  are  created 
dynamically  by  processes  in  execution.  The 
VMS  executive  was  modified  to  set  the  access 
class  of  a  newly  created  object  of  any  of 
these  types  to  the  access  class  of  the 
creating  process,  except  in  the  case  of  a 
global  section  "backed"  by  a  disk  file;  in 
that  case  the  global  section  is  given  the 
access  class  of  the  file.  The  access  classes 
of  objects  of  these  types  may  be  altered  by 
the  SET  CLASS  command  (given  sufficient  user 
privilege)  and  displayed  by  the  corresponding 
SHOW  CLASS  command. 


4.10  Labeling  Output 

For  many  users,  the  "bottom  line"  ..f  a 
system  that  implements  mandatory  controls  is 
the  ability  to  produce  properly  labeled 
printed  output.  As  part  of  the  SE/VMS 
development,  a  print  symbiont  was  developed 
that  verifies  the  requesting  user’s  mandatory 
access  to  a  file,  then  produces  a  listing 
with  labeled  header  and  trailer  pages  and 
optional  top  and  bottom  labels  on  each  page. 
The  layout  of  the  header,  trailer,  top  and 
bottom  labels  are  custom i zeable .  A  SE/VMS 
utility  allows  the  format  to  be  defined  for 
each  unique  combination  o'  security  levei  and 
ca tegor i es . 


4.11  Aud  i  t ing 

The  VAX/VMS  security  auditing  facilities 
seemed  to  audit  the  "right  things"  for 
SE/VMb,  but  were  insensitive  to  mandatory 
security  access  classes.  For  SE/VMS,  the 
existing  r. acuities  were  enhanced  to  record 
access  class  information  where  appropriate 
(login,  file  access). 

To  allow  a  reasonable  level  of  audit 
selectivity  at  audit  trail  collection  time 
and  avoid  flooding  the  system's  audit.  log 
file  the  VAX  /VMS  sxscut  i  vc  wss  to 

allow  system  manager  selection  of  auditing  of 
a  LI  file  access  at  or  above;  a  selected 
security  class.  A  command,  SAUDIT,  was 
implemented  as  part  of  SE/VMS  to  allow  a 
system  manager  to  select  the  access  class 
threshold  for  auditing  (Figure  6). 


SAUDIT/ ENABLE/ SECRECY-  ( LEVEL : SECRET, 
CATEGORIES : ( APPLE , GRAPE ) ) 

Figure  fc .  Selecting  the  Audit  Threshold  Access 

C  lass 


4.12  Mail 

The  VAX/VMS  MAIL  utility  is  used  to  send 
messages  between  users.  As  distributed  with 
Version  4.2,  it  would  only  be  possible  to 
send  mail  between  users  at  the  unclassified 
level.  The  SE/VMS  development  project 
modified  MAIL  so  that  a  message  can  be  sent 
from  a  process  to  any  user  who  could  read  a 
file  at  the  sending  process’  access  class. 
In  some  cases,  the  receiver's  copy  of  the 
message  may  have  its  access  class  raised  to 
the  receiver's  minimum  access  class.  The 
receiving  process  can  only  respond  with  a 
message  built  into  the  mail  program  that  says 
"user  HAS  READ  YOUR  MESSAGE". 


4.13  Implementation  Considerations 

The  implementation  of  SE/VMS  was 
simplified  by  the  level  of  support  for 
mandatory  security  already  present  in 
Versions  4.2  and  4.4  of  VAX/VMS,  and  by  the 
structure  of  VAX/VMS.  The  normal  functions 
of  an  operating  system  kernel  are  performed 
by  the  VAX/VMS  executive.  The  executive 
performs  such  functions  as  opening  files  and 
checking  access.  Support  functions  are 
performed  by  programs  (images)  that  are  part 
of  the  operating  system,  but  run  in  the 
context  of  the  process  that  invokes  them.  In 
some  cases,  these  operating  system  images  may 
have  privileges  of  their  own;  more  often  they 
inherit  any  special  privileges  of  the  user  on 
whose  behalf  they  operate. 

SE/VMS  implements  mandatory  security 
controls  in  VAX/VMS  by  first  enabling  the 
mandatory  control  support  features  that  are 
always  present  in  the  VAX/VMS  executive.  In 
a  few  cases,  the  executive  has  been  modified 
(patched)  to  add  features  not  yet  supported 
by  VAX/VMS.  For  example,  selective  auditing 
by  security  access  class,  and  filling  in  ORBs 
with  classification  information  are 
implemented  by  patches  to  the  executive. 

A  number  of  the  user  and  system  manager 
support  functions  in  SE/VMS  are  implemented 
by  images  that  are  present,  but  do  not 
support  mandatory  controls,  in  the  standard 
VMS  product.  In  these  cases,  SE/VMS  simply 
modifies  the  source  programs  for  the  images, 
then  replaces  these  images  at  SE/VMS 
installation  time.  This  is  the  case  for  the 
Authorize,  LOGINOUT,  and  Directory  utilities. 
In  each  case,  the  required  modifications  are 
localized  to  small  segment:,  of  the  image  in 
question. 

Finally,  some  of  the  components  of 
SE/VMS  required  the  development  of  entirely 
new  programs  (though  perhaps  based  on 
existing  VAX/VMS  software).  For  exampLe,  the 
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5  LIMITATIONS,  EXPERIENCE  AND  FUTURE 
DIRECTIONS 

5.1  LimitaHuns  And  Support 

The  sections  above  should  have  made 
clear  the  fact  that  SE/VMS  is  intended  to 
provide  an  initial  mandatory  control  facility 
for  VAX/VMS.  This  section  considers  what  is 
"not  provided"  with  5E/VMS. 

The  combination  of  VAX/VMS  Version  4.4 
with  SE/VMS  provides  a  fairly  complete  set  of 
mandatory  control  facilities  at  the  operating 
system  level.'  Users'  processes  can  create, 
delete,  read,  and  write  objects  at  the 
operating  system  level,  and  those  operations 
will  be  constrained  by  and  consistent  with 
the  requirements  of  the  mandatory  security 
con  t  ro 1 s  . 

Two  major  system  objects  -  event  flag 
clusters  and  lock  blocks  -  are  not  labeled. 
Event  flag  clusters  are  sets  of  32  bits, 
normally  used  for  posting  events,  that  can  be 
used  for  interprocess  communications.  A 
process  can  access  two  shared  event  flag 
clusters  at  a  time.  Lock  blocks  are 
structures  used  to  control  access  to  shared 
resources.  They  can  optionally  be  associated 
with  a  16-byte  value  block  that  can  be  used 
to  communicate  information  among  ptocesses 

sharing  the  res>urce.  Both  lock  blocks  and 
and  event  flag  clusters  are  allocated 

dynamically  by  the  system. 

There  are  a  few  feature  shortfalls  that 
might  be  expected  to  be  resolved  in  a 
full-fledged  system.  For  example: 

o  Terminals  associated  with  terminal 
servers  (such  as  DECs e r ve r- 1 0 0s )  can 
no1  be  assigned  access  classes 

individually;  all  such  terminals 

must  be  given  the  same  access  class  as 
a  group. 

o  Some  of  the  auditing  facilities  are 
relatively  coarse  and  not  well-tuned 
for  the  mandatory  controls.  For 
example,  one  cannot  tell  from  the 
error  coding  in  the  audit  trail 
whether  a  tile  access  attempt  was 
rejected  because  of  the  mandatory 
•ontrols  or  the  discretionary 
con  t  ro  1  s  . 

These  and  'ther  equivalent  shortcomings 
demonstrate  that  SE/VMS  is  still  an  evolving 
system  at  the  operating  system  level,  rather 
than  a  completely  finished  one. 

The  area  where  SE/VMS  will  present  the 
greatest  challenge  to  its  users  is  not  in  the 
domain  of  operating  system  features,  but  in 
application  structure.  It  is  clear  that  an 
ordinary  unprivileged  VAX/VMS  application 
program  that  does  not  attempt  to  cross  access 
class  boundaries  will  function  correctly 
under  SE/VMS.  It  i  ■;  equally  clear  that  a 
complex  applic-nion  that  operate:,  on  multiple 
files,  perhaps  of  different  access  classes, 
may  find  itsell  broken  by  SE/VMi  . 

Dili''  complex  u  pp  i  i  ca  t  l  on ::  mus1  he 

install'd  "with  privilege”  in  i  VAX/V.M  S 


system.  Those  applications  may  have 
sufficient  power  to  defeat  SE/VMS, 
eliminating  part  of  the  benefit  of  the 
mandatory  controls.  On  the  other  hand,  some 
privileged  applications  (MAIL  is  an  example) 
may  not  have  enough  power  to  overcome  the 
mandatory  controls.  The  key  point  is  that 
there  is  a  significant  amount  of  engineering 
required  to  make  complex  applications  operate 
correctly  in  an  environment  where  mandatory 
security  controls  are  being  enforced,  and 
that  engineering  has  not  yet  been  done  for 
the  applications  that  may  be  asked  to  operate 
under  SE/VMS. 

SE/VMS  may  interact  in  unexpected  ways 
with  VAX/VMS  applications.  A  pool  of 
specialists  has  been  trained  in  mandatory 
controls  in  general  and  in  SE/VMS  in 
particular  so  they  might  understand  their 
effects  on  applications.  Such  training  can 
provide  specialists  with  the  skills  necessary 
to  provide  support  for  mandatory  controls  in 
the  future.  This  support,  in  addition  to 
basic  installation  of  the  SE/VMS  software, 
could  include  defining  initial  security 
policy,  setting  up  device  and  directory 
structures,  and  analyzing  the  impact  of 
SE/VMS  on  applications. 

On  hearing  a  description  of  the  features 
of  SE/VMS,  a  listener  might  naturally  be 
expected  to  ask  "has  it  been  submitted  for 
evaluation?"  Digital  believes  that  SE/VMS 
meets  many  of  the  TCSEC  requirements  for 
Class  Bl,  Labeled  Security  Protection, 
however,  absent  a  full  developmental 
evaluation,  it  seems  likely  that  there  are 
specific  features  that  fall  short  of  the 
requirements  of  Class  Bl.  In  addition,  the 
documentation  for  SE/VMS  is  not  structured  in 
accordance  with  the  requirements  of  the 
TCSEC,  and  the  requirements  for  complete 
functional  testing  of  the  security  features 
have  not  been  met.  Digital  has  requested 
that  NCSC  initiate  a  developmental  evaluation 
of  SE/VMS.  The  intention  of  requesting  this 
evaluation  is  primarily  to  provide  better 
insight  into  what  might  be  required  to  make  a 
future  release  of  VAX, VMS  meet  the 
requirements  of  Class  Bl. 


5.2  Experience  With  SE/VMS 

As  par;  of  its  evaluation  of  the  impact 
of  inandaLoiy  controls  on  VMS  and  its  users. 
Digital  has  provided  copies  of  SE/VMS  to  a 
selected  set  of  VAX/VMS  users.  Because  this 
paper  was  prepared  shortly  after  the 
evaluation  copies  of  SE/V’.J  were  distributed, 
there  is  no  experience  to  report.  It  is 
anticipated  that  some  comments  on  user 
experience  with  SE/VMS  will  be  included  in 
the  presentation  of  the  paper  at  the  Ninth 
National  Computer  Security  Conference. 


5.1  Directions  For  The  Future 

The  discussion  above  clearly  points  the 
way  towatd  a  possible  future  release  of 
VAX/VMS  meeting  the  TC EEC  requirements  for 


Class  Bl.  In  addition,  Digital  is  continuing 
advanced  development  projects  aimed  at 
evaluating  the  feasibility  of  developing  a 
Class  A1  security  kernel  that  would  be 
compatible  witn  VAX/VMS.  Advanced 
development  and  architecture  studies  are  also 
continuing  to  examine  the  impact  of  mandatory 
controls  on  VAX/VMS  layered  software 
products.  An  additional  focus  of  advanced 
development  work  is  the  need  for  enhanced 
security  in  Digital's  DECnet  wide-area 
network  and  Ethernet  local-area  network 
products.  As  these  advanced  development 
projects  reach  maturity,  they  are  likely  to 
form  the  basis  for  future  papers  like  this 
one . 
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Abstract:  This  paper  describes  the  specification  and  verification  of 
a  prototype  line  printer  labeler  for  the  Secure  Ada  Target  (SAT)  machine 
currently  under  development  at  the  Honeywell  Secure  Computing 
Technology  Center.  There  are  two  types  of  constraints  on  a  secure 
labeler— functionality  requirements  on  the  labeler  itself,  and  constraints 
on  tiie  context  in  which  the  labeler  is  called.  The  approach  described 
addresses  both  types  of  constraints.  Verifying  properties  of  the  labeler 
itself  is  an  interesting  but  straightforward  exercise  in  program 
verification— in  this  case,  code  level  verification.  This  verification  alone, 
however,  does  not  ensure  that  the  labeler  is  unavoidably  encountered  in 
moving  text  fiom  user  domain  to  line  printer  or  that  the  output  of  the 
labeler  cannot  be  altered  by  user  programs.  Such  constraints  require  the 
construction  of  an  assured  pipeline  and  are  easily  handled  by  the  SAT 
type  enforcement  mechanism.  Type  enforcement  is  described  and  shown 
to  have  broad  applicability  in  handling  such  context  coin,  trail  its. 


INTRODUCTION 

Designers  of  secure  computing  systems  go  to  considerable  lengths  to 
guarantee  the  proper  segregation  of  internal  information.  This  care  can 
be  wasted  if  the  information  is  compromised  externally  or  at  the  1/0 
interface  between  the  computer  and  its  external  environment  Thus,  the 
DoD  Trusted  Computer  cystems  Evaluation  Criteria1  (TCSEC)  specifies 
a  labeling  requirement  on  systems  at  or  above  the  B  level  of  certification. 
For  human-readable  output  this  requires  that: 

The  TCB  |Trusted  Computer  Base]  shall  mark  the  beginning 
and  end  of  all  human-readable,  paged,  hardcopy  output  (e  g., 
line  printer  output)  with  human-readable  sensitivity  labels 
that  properly  represent  the  sensitivity  of  the  output.  The 
TCB  shall,  by  default,  mark  the  top  and  bottom  of  each  page 
of  ...  output  with  hum  in  loadable  sensitivity  levels  that 
properly  represent  the  overall  sensitivity  of  the  output  or  that, 
properly  represent  the  .sensitivity  of  the  information  on  the 
page. 

This  paper  describe  «pj'«*v'»-li  *v  ratifying  *!;:s  requirement  a 

prototype  line  printer  labeler  for  the  Secure  Ada  T.ugei  (SAT)  machine 
currently  under  development  at  the  Honeywell  Secure  Computing 
Technology  Center.  SAT  is  intended  to  satisfy  or  exceed  all  of  the 
TCSEC  requirements  for  A!  certification.  .Among  these  is  the 
requirement  for  design  verification.  Consequently .  the  labeler  described 
here  has  been  designed  so  that  it  can  be  formally  verified.  This  places 
constraints  on  the  labeler  that  make  the  design  somewhat  loss  flexible 
than  has  apparently  brnn  true  for  most  iclaird  efforts”'*.  We  examine 
the  implications  of  the  requu eim’iii  for  fouual  verification  on  trusted 
software  Labeling  is  one  of  a  number  of  ar^as  which  require  code  which  is 
commonly  called  trusted  However,  uiilik*  some  other  trusted  software 
such  as  a  downgraded,  wc  invi-sl  trust  in  the  code  not  because  it  is 
privileged  to  violate  some  aspect  of  die  security  policy  but  beeau-e  its 
functioning  is  crucial  to  I  he  maim  enam  ••  of  secuuly  in  the  system  For  ,\ 
discussion  of  this  disi im'lioti  see’  . 

Our  presentation  is  as  follows-  m  section  2  w»*  outline  the  security 
requirements  for  a  labeler  in  an  A l  context  Section  3  describes  the  SAT 


A  ho  vuih  th*-  ln.UiD»io  f-»r  s-i«|,-*  i*n.l  r<>iu|»n<>r  TIi* 
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prototype  line  printer  labeler  and  the  way  in  which  the  security 
constraints  have  been  met.  Finally,  we  draw  some  conclusions  in  section 

4. 

THE  LABELING  REQUIREMENTS 

The  basic  requirement  for  a  labeler  is  simply  to  associate  the 
correct  sensitivity  label  with  a  document  and  to  guarantee  that  the  label 
is  affixed  in  such  a  way  that  ii  will  appear  in  the  proper  formal  and 
position  on  the  resulting  human-readable  output.  This  sccuia  a  simple 
requirement:  for  a  line  printer,  for  example,  simply  partition  the  input 
stream  into  a  sequence  of  pages  with  mi  appropriate  character  string  (the 
label)  inserted  at  appropriate  points  in  i he  output  stream.  Thus,  the 
labclci  procedure  lakes  as  input  a  character  sequence  and  a  security  level 
(or  the  corresponding  human-readable  label  associated  with  that  level), 
and  generates  as  output  *  character  sequence  with  labels  and  page  breaks 
inserted  at  the  approp- late  positions  in  the  sequence. 

However,  the  la  »elcr  is  merely  one  program  executing  in  concert 
with  many  others.  Any  assurance  provided  by  the  labeling  process  is  lust 
if  the  input  can  be  manipulated  to  insert,  for  example,  top  secret 
information  into  an  input  stream  the  labeli .-  is  to  mark  as  unclassified. 
Similarly,  the  labeling  requirement  is  circumvented  if  the  output  stream 
can  be  altered  to  replace  any  label  by  some  string  representing  a  label  for 
a  lower  security  level.  Thus,  there  are  two  components  to  the  labeling 
requirements:  correctness  constraints  on  llic  functionality  of  the  labeler 
itself,  and  integrity  constraints  on  the  handling  of  documents  in  the 
"information  pipeline"  that  ends  at  the  line  printer  physical  device 

The  correctness  constraints  are  specifications  on  the  labeler  code. 
There  is  e  msiderable  flexibility  in  defining  these  constraints.  For 
example,  the  TCSEC  docs  not  -ecify  the  output  page  format  other  than 
the  placement  ol  the  labels;  m.«  does  it  specify  the  particular  characters 
permitted  in  the  output  sequence.  To  restrict  the  possibilities  for  covert 
channels  in  the  output  formatting6  and  because  of  the  desire  to  formally 
verify  the  code,  the  SAT  prototype  labeler  specification  imposes  fairly 
stringent  restrictions  on  the  labeler  functionality.  These  may  be  stated 
as  follows: 

Al.  The  labeler  must  partition  the  input  stream  into  pages,  each 
of  which  begins  and  ends  with  a  label.  Pages  are  defined  by 
t lie  placement  of  carriage  control  characters  in  the  output. 

Thi*-  label  must  be  the  human-readable  characlei  siring 
associated  by  the  system  adiniiiL;.. alor  with  the  level  of  ihe 
document  represented  in  the  input  stream.  (We  are 
considering  only  single-level  documents  in  tins  discussion. 
Handling  c>r  muki-levei  objects  and  documents  in  ihe  SAT  is 
currently  under  consideration.)  The  page  sue  and  page  width 
are  device-dependent  paramclcis.  Output  pages  must  satisfy 
those  size  constraints  and  contain  only  characters  fiom  a 
certain  limited  set. 

*\2  The  document  represented  by  the  input  stream  must  nol  be 
unacceptably  altered  by  the  labeling  process.  Acceptable 
alterations  include  ihe  nisei  lion  of  labels  at  the  appi  upiiate 
placcs,  breaking  lines  that  exceed  the  permitted  line  length, 
removing  characters  that  arc  not  within  the  permuted 
character  set.  and  deleting  characters  that  would  be 
oversir ink  (The  current  design  docs  not  permit  undei lining 
or  highlighting  or  text  by  ovei sinking.  This  luiutaliou  is  a 
Consequence  of  the  way  Hi  which  lilies  are  maintained  in  the 
pagination  pioeess;  the  himtalion  could  he  changed  hi 


jb 


subsequent  designs  )  The  sequence  of  printing  characters  in 
the  output  is  a  subsequence  of  the  printing  characters  in  the 
input. 

The  constraints  on  the  environment  in  which  the  labeler  is  invoked  are 
designed  to  preserve  the  integrity  of  its  inputs  and  outputs.  This  is  more 
a  function  of  the  overall  security  mechanism  in  SAT  than  of  the  labeler 
itself.  These  constraints  may  he  stated  follows- 

111.  The  level  associated  with  the  (input]  document  must  be  an 
accurate  representation  of  the  mmimIhiiv  of  the  information 
contained  in  the  document.  Tins  implies  that  the  level  of  a 
document  is  not  accessible  to  manipulation  by  arbitrary  user 
programs.  Moreover,  the  content  of  the  document  is  not 
subject  to  alteration  by  arbitrary  user  programs. 

B2.  A  stronger  restriction  is  necessary  to  avoid  mislabeling:  the 
labeled  document  may  only  be  output  on  a  device  for  which  it 
was  labeled:  no  other  manipulation  should  be  possible.  The 
output  document  must  not  be  accessible  to  manipulation  by 
arbitrary  user  programs. 

B3.  The  labeler  is  limited  to  dealing  with  the  files  passed  as 
parameters.  That  is,  tin.  labeler  is  constrained  from  accessing 
arbitrary  files  even  if  the  system's  genera)  object  access 
constraints  (e  g.,  the  mandatory  and  discretionary  security 
policies)  would  otherwise  allow  it. 

These  restrictions  on  the  handling  of  the  document  outside  the  labeler 
arc  more  difficult  to  insure  in  most  systems  than  the  constraints  on  the 
behavior  of  the  labeler  itself.  Verifying  properties  of  the  labeler  merely 
involves  examining  the  code  of  the  labeler.  The  other  properties  relate  to 
the  environment  in  which  the  labeler  is  invoked.  They  reflect  on  the  way 
in  which  general  documents  may  be  handled  in  the  system.  Systems  that 
enforce  the  Bell  and  LaPaduU  model  of  security7,  for  example,  typically 
guarantee  adherence  to  constraint  Bl.  Initial  assignment  of  levels  is  not  a 
function  of  the  system,  but  once  information  lias  been  classified,  the 
Simple  Security  Property  and  the  ‘-Property  ensure  that  high  level 
information  cannot  flow  into  objects  at  lower  levels.  The  Tranquility 
property  requires  that  the  level  of  an  object  remain  fixed  throughout  its 
lifetime. 

These  mandatory  constraints,  however,  do  not  prevent  the 
manipulation  of  the  labeler's  output  by  user  programs  at  appropriate 
levels.  That  is.  a  program  operating  on  behalf  of  a  top  secret  user  might 
be  able  to  alter  the  labels  on  a  top  secret  output  document  without 
running  afoul  of  the  mandatory  constraints.  One  might  encapsulate  the 
labeler  and  printer  mechanisms  so  that  there  is  no  point  at  whHi 
intervention  is  possible.  This  encapsulation  violates  the  principle  of 
modular  design  that  dictates  that  separate  functions  should  reside  in 
separate  modules.  Alternatively,  one  can  impose  additional  integrity 
constraints  which  makes  the  output  Tile  inaccessible  to  user  programs 
because  their  integrity  level  is  too  low;  this  is  the  SCOMP  approach0. 
Boehm  ami  Kain  have  shown  that  hierarchical  integrity  approaches 
that  aie  sufficient  to  meet  the  Bl,  B2,  and  113  resti ictions  necessarily 
involve  trust  since  data  must  “flow  up"  in  integrity.  The  SAT  type 
m force mrut  tiU'cliaiiisin  addresses  these  issues  with  a  novel  approach 


Wry  little  work  has  been  dune  on  the  labeling  problem.  Kmih 
describes  a  hue  printer  labeling  package  for  an  IBM/370-cotnpatibie 
machine  with  the  MVS  operating  sjstem.  This  differs  from  our  work  in 
that  i.  describes  a  mechanism  used  in  a  single-level  system,  am)  is  not 
formally  wnfied.  Itiulrll~  examines  the  labeling  of  screen  output  at  a 
f.urh  high  grauularit)  Again,  tin- >\ stem  is  not  formally  venfied.  The 
only  xorified  routines  similar  in  spnit  to  the  SAT  prototype  labeler  are 
the  proofs  of  the  trusted  device-driver  routines  of  SCOMP10  However, 
this  verification  was  don**  at  a  vi-ry  high  level,  and  it  was  assumed  that,  a 
process  existed  u hit'll  did  the  labeling  correctly  We  ate  not  aware  of 
any  implement ation-lr\ e)  proof  of  a  labeler  process 


LABELING  AND  SAT 

The  treatment  of  labeling  in  the  SAT  system  is  presented  in  two 
parts.  We  first  examine  the  labeler  itself  and  the  properties  that  it  is 
proven  to  satisfy.  These  are  constraints  A I  and  A  2  of  the  previous 
section.  We  then  present  the  SAT  type  enforcement  mechanism  and 
show  how  this  preserves  the  integrity  of  the  output  data  after  it  lias  been 
labeled  (constraint  B2).  This  mechanism  is  quite  general,  and  we 
indicate  bow  our  particular  problem  is  only  a  special  instance  of  a  more 
general  problem  of  restricting  access  to  classes  of  objects. 

The  Prototype  Labeler 

The  functional  correctness  of  the  labeler  is  defined  in  terms  of 
constraints  Al  and  A2  above.  The  input  to  the  labeler  is  a  sequence  of 
characters  and  a  level.  The  output  is  a  sequence  of  characters  that  is  the 
properly  massaged  version  of  the  input-labels  have  been  inserted  at  tin- 
appropriate  places  and  the  output  sequence  is  a  legitimate  transformation 
of  the  input.  The  labeler  was  fully  specified  and  mechanically  verified 
using  the  Gypsy  Verification  Environ muit11  ,2.  The  complete  Gypsy  text 
is  given  in  the  appendix 

1*  or  purposes  of  verification,  the  labeling  process  is  broken  into  two 
steps.  In  step  one,  a  paginator  process  breaks  the  input  into  a  sequence 
of  pages  of  correct  size.  Extraneous  characters  are  discarded  at  this 
point.  The  paginator  is  verified  to  twe  properties:  that  the  resulting 
sequence  contains  only  correct  pages,  and  that  the  printing  characters  in 
this  sequence  are  a  subset  of  those  in  the  input.  It  is  still  conceivable  that 
the  labeler  could  signal  information  by  the  sequence  of  characters 
deleted.  We  consider  this  possibility  unlikely  and  don’t  attempt  to 
prevent  it. 

There  are  two  global  constants,  Logical  __  Page  _  Length  and 
Logical _ Page _ Width,  in  the  pccification  that  characterize  the  amount 
of  space  on  a  line  printer  page  (minus  the  amount  needed  to  add  the 
labels  at  the  top  and  bottom  of  the  page).  A  correct  page  has  exactly 
Logical  _  Page _ Length  lines,  each  of  which  is  a  sequence  of  at  most 
Logical  _  Page  _  Width  printing  characters.  Printing  characters  are  those 
in  the  ASCII  character  set  between  space  ami  "  —  ",  a  range  that  excludes 
all  control  characters.  (This  range  was  chosen  because  ceitain  devices 
allow  device  characteristics  to  be  reset  by  sequences  of  control  characters. 
Passing  to  the  device  sequences  of  characters  which  might  reset  page 
boundaries  or  selectively  disable  the  print  head  might  vitiate  the 
labelling  requirement.  We  simply  di.-allow  all  control  characters;  a  more 
selective  filter  is  obviously  desirable.)  Other  characters  allowed  in  the 
paginator  output  are  carnage  return  (OR),  line  feed  (LP),  and  form  feed 
(FF);  rhesc  have  their  typical  meaning  in  the  division  of  the  input  into 
lines  and  pages.  A  FF  in  the  input  sequence,  for  example,  causes  the 
current  page  to  be  filled  out  with  mill  lines  and  a  new  page  to  begin. 
Other  ASCII  characters  in  the  input  sequence  are  discarded  The  formal 
(Gypsy)  specification  for  pagination  of  the  outpuL  is  given  by  the 
following  three  recursive  function  definitions: 

function  CORRECT _PAGE_SEQUDJCE  (pages,  pageseq) :  boolean  = 
begin 

exit  (assume  result  iff 

(  pages  =  null (pageseq) 
or 

(  correct,  naj* 

*  correctpagesequence  (nonflrst  (pages))))); 
end:  (correct_page_sequence} 

function  CORRECT  PAGE  (pg  page) -  boolean  - 
begin 

exit  (assume  result  iff 

(  size(pg)  =  logical  page  length 
k  (al 1  1  Integer, 

1  In  [1  size  (pg) ] 

->  correctllne  (pfifi])))). 
end,  (correetpage) 

function  CORRECTLINE  (In.  line),  boolean  = 
begin 

exit  (assume  result  iff 

(  slze(ln)  le  logical_page_vldth 
k  (al 1  1  integer. 

1  In  (1  si ze  ( In) J 
->  priniingcharacter  (ln[l))))). 
end.  correct  line) 
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This  specification  may  be  considered  slightly  flawed  in  that,  references  lo 
priuiiM  g  _  c/mrucipr  should  not  appear  m  tin-  formatting  constraint,  but 
rather  in  the  textual  integrity  constiaint  described  below  That  is,  for  a 
line  to  be  correct  from  a  formatting  standpoint  it  need  only  be  of  the 
correct  length.  Subsequent  versions  wili  include  this  change. 

The  other  crucial  property  of  the  labeler  is  that  it  not  distort  the 
input.  This  is  handled  in  a  very  simple  fashion.  As  the  input  sequence  is 
scanned,  the  printing  characters  are  extracted.  Those  ale  the  characters 
that  are  placed  into  the  output  pages.  They  are  also  recorded  in  a 
character  sequence  pur  gel  it,  which  Is  compared  to  the  input  sequence. 
The  property  that  is  proven  is  that  the  sequence  of  priming  characters  in 
purgctxt  is  equal  to  the  printing  characters  of  tli input  sequence 
extracted  by  a  call  to  the  function  Purge_Text  defined  .»s  follows 

function  PURGE  TEXT  (lnseq  text).  t«xt  = 
b«gin 

exit  (assume  result  = 

(if  lnseq  =  null (text) 
then  null (text) 
else 

(if  print lng_ch»:racter  (lns»q[i)) 
then  iiiseqfl] 

>  purge  text  (nonflrst  (lnseq)) 
else  purge  text  (nonflrst  (lnseq)) 
fi) 

fl)) ; 

end,  (purge_text)** 

This  property  is  almost  laulologous  It  would  be  much  more  satisfying 
to  be  able  to  prove  that  the  the  purged  version  of  the  filial  labeled 
output  is  identical  to  the  purged  input.  This  is  not  possible  for  two 
reasons.  Inserting  the  labels  adds  printing  characters  to  the  output 
which  were  not  present  in  the  input.  Thus,  given  the  definition  of 
Purge __ Text  above,  this  property  is  not  true  unless  one  ignores  the  labels 
in  the  output.  But  there  is  no  convenient  way  to  distinguish  labels 
inserted  by  the  labeling  process  from  identical  character  strings  which 
might  have  appeared  in  the  input  stream. 

Also,  the  way  in  which  Oils  and  Lb's  are  handled  by  the  paginator 
potentially  causes  some  printing  characters  from  the  input  to  be  lost  in 
the  output  A  single  CR  resets  the  current  line  to  null,  which  is  the 
paginator  analog  of  moving  the  print  head  to  the  beginning  of  the  line. 
However,  this  causes  any  characters  on  the  current  line  to  be  lost.  Thus, 
a  proper  new  line  sequence  should  he  in  the  form  of  a  LF  followed  by  a 
CR.  The  Id*'  causes  the  current  line  to  be  appended  to  the  current  page; 
the  CR  sets  the  current  line  to  null,  and  (conceptually)  positions  the 
write  head  at  the  beginning  of  the  line.  This  rather  curious  handling  of 
CR  is  necessary  to  guarantee  that  the  printing  characters  of  the  page 
sequence  are  a  subsequence  of  the  input,  something  that  would  not  be 
true  if  the  initial  characters  on  a  line  could  be  overwritten  following  a 

CM. 

Type  Enforcement  and  the  Labeler  Environment 

Proving  tin*  correct  operation  of  the  labeler  is  not  sufficient  to 
ensure  that  labeling  is  earned  out  m  accordance  with  tin.*  TCiiEO 
requirements.  It  remains  to  show  that  the  labeled  text  is  not  altered 
before  it  can  be  output.  The  SAT  mechanism  that  guarantees  the 
integrity  of  such  text  is  called  liic  i\j\n  ui/umjiiui.1  and  is 

fully  described  elsew-hci eB  ,  so  we  merely  summarize  it  here. 

Associated  with  each  object  m  the  SAT  system  is  a  sccuuly  level, 
an  access  control  list  {ACL),  and  a  type  Each  subject  lia-s  an  associated 
level.  User,  and  domain  The  level  attributes  of  subjects  and  objects  arc 
used  in  enforcing  the  mandatory  security  constraints,  and  the  user  ami 
ACL  fields  in  enforcing  discretionary  access  controls.  The  inandaioiy 
and  discretionary  constraints  are  straightforward  interpretations  of  tln*M* 
mandated  by  the  TCSHC.  1(  is  the  use  of  the  subject  domain  and  object 
type  fields  that  allows  us  to  guarantee  the  integrity  of  the  labeled  text. 
A  domain  is  an  abstraction  of  the  role  that  a  subject  is  currently  filling, 
and  a  type  is  an  abstraction  of  the  format  of  an  object  When  the 
labeler  is  executing  «n  behalf  of  a  particular  subject  that  subject  must  be 
in  a  different  domain  than  when  executing  typical  user  code  I.uLrlnl 
text  and  utilabcUd  text  arc  of  different  object  types.  The  labeler  domain 
is  afford'  d  read  access  lo  unlabeled  text  ami  write  access  to  labeled  text, 
and  is  the  only  domain  with  writ-  access  lo  labeled  text  objects  Tin- 

•  .ire  I  *-  •  :!!■■  ill'-  <iyi*vi  ,ux  wlu.'li  ;j.1-|  in  Hrinriii  ->ii'h  i  Jir-  ••  n  .|  i  if  -i 
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Printer  device  driver  is  in  another  domain,  the  only  domain  afforded  n-ad 
access  to  objects  or  labeled  text  type;  the  printer  domain  cannot  read 
obiects  of  any  type  except  labeled  text.  The  relevant  type  enforcement 
constraints  are  pictured  in  Figure  3-1. 


Figure  Is  Information  flow  through  the  labeler  domain. 

Type  enforcement  constraints  are  recorded  in  a  matrix,  the  Domain 
Definition  lable  (DD1),  indexed  on  rows  by  domains  and  on  columns  by 
types.  An  entry  in  the*  matrix  indicates  whether  read/ w rile/ execute 
access  is  granted  a  subject  executing  in  the  given  domain  to  objects  of 
the  given  type.  This  mechanism  allows  the  construction  of  an  assured 
pipeline8  that  maintains  the  integrity  of  labeled  data.  Every  access  is 
mediated  by  the  reference  monitor,  which  determines  access  rights  by 
consulting  the  DDT  in  addition  to  the  mechanisms  for  detvi  mining  the 
mandatory  and  discretionary  constraints. 

With  a  DDT  configured  as  indicated  above,  data  of  unlabelcd  type 
can  be  manipulated  by  subjects  executing  in  user  domain,  but  such 
subjects  have  no  access  lo  labeled  data.  The  labeler  can  read  uiilabelrd 
data,  but  write  only  labeled  data.  The  printer  domain  permits  only 
reading  of  labeled  data.  These  constraints  suffice  to  enforce  tin*  rule  that 
no  user  process  can  remove  or  alter  tin-  labels  that  the  labeler  has 
inserted  or  signal  information  covertly  by  modifying  the  labeled  text. 
Attempts  to  do  so  are  violations  of  the  type  enforcement  constraints 
encoded  in  the  DDT  and  are  prevented  bv  tin*  reference  monitor. 
Similarly,  the  labeler  cannot  alter  user  files  in  any  way.  No  text  can 
bypass  the  labeler  since  the  labeler  domain  is  the  only  domain  that  can 
output  data  of  labeled  type  and  the  printer  domain  will  input  only 
labeled  text. 

The  type  enforcement  mechanism  thus  provides  a  solution  to  the 
problem  of  maintaining  the  integrity  of  labeled  data.  The  .solution  is  not 
at  all  restricted  to  this  particular  problem  but  rather  provides  the 
solution  to  a  variety  of  similar  concerns.  An  encryption  device,  for 
example,  must  be  unavoidably  encountered  by  certain  ty,/Cs  of  data  being 
propagated  onto  an  unsecure  network.  This  can  be  guaranteed  using  the 
type  enforcement  mechanism  in  an  exactly  analogous  fashion 

The  proof  of  the  SAT  type  enforcement  mechanism  is  similar  to  the 
proof  of  the  SAT  mandatory  constraints  and  is  fully  elsewhere 
described11,1^  Briefly,  it  involvt  proving  that  the  reference  monitor  is 
unavoidably  consulted  whenever  an  access  is  granted  and  that  the  access 
decisions  of  the  reference  monitor  always  accord  with  the  constraints 
recorded  in  the  DDT  A  recent  paper  describes  the  formalization  and 
proof  of  type  enforcement  and  .similar  security  policies  in  a  general 
context13. 

CONCLUSIONS 

The  prototype  labeler  obviously  does  not  provide  all  the 
funclioualii .  one  would  like  in  a  general  purpose  line  printer  labeler. 
For  exampie.  the  deesgp  rould  securely  permit-  some  additional  character.* 
to  be  handled,  make  use  of  tile  features  oi  ••smalt”  uuijuu  devices  such 
as  resettable  device  parameters,  and  aliuw  overall  iking.  Also,  a  more 
general  labeler  could  be  written  with  device  type  paraim-t ns  Such  » 
labeler  would  be  passed  a  device  type  and  consult  a  lable  to  obtain  i J ■ 
corresponding  device  parameters  Labeling  tln  u  would  be  only  one  part 
of  a  larger  text-formatting  effort,  with  variable  Jesuits  depending  upon 
the  intended  target  output  device  This  is  tin*  approach,  foi  example,  of 
the  Scribe  text  foriiialling  system^'  Tin-  dime  for  sm.li  increas'd 
functionality  must  he  weigh'd,  however,  against  the  additional  effort 
that  would  he  required  fur  foimal  verification  of  the  lahelei  properties. 

Previous  verified  Secure  systems  have  been  formally  \eiifieil  at  the 
design  level  Ii  has  been  our  intention  to  pii-h  ventilation  uf  the  S.\T 
system  as  close  ;us  possible  10  tin-  implement  at  ion  level  Note  (li.it  tins 
actually  provides  a  level  of  assiuaine  beyond  1 1ml  nquijed  for  A I 
certification.  The  traditional  view  has  been  that  code-level  proofs  are 
beyond  the  current  stale  of  the  art  in  pn>>'ruui  \  ci  ifual  um.  We  inlem! 
lo  test  that  asseition  I  In*  labt-h-i  rode.  l«ir  mstaiiee,  i>>  uiitien  in 
executable  Uvpsy  code  and  requires  only  a  hand  or  im  cli  unc  il 
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translation  to  the  actual  implementation  language,  a  straightforward 
process  for  the  constructs  involved  The  Gypsy  Verification  Environment 
contains  mechanical  tools  Tor  translating  Gypsy  programs  to  Ada  or  to 
Bliss. 

The  requirement  that  the  lahcler  be  formally  verified  placed 
constraints  on  its  sine  and  complexity  The  proof  logs  of  just  the 
paginator  routine  and  accompanying  lemmas,  for  instance,  arc  some  150 
pages  in  length  and  the  proof  is  rather  tedious.  This  is  more  a  reflection 
on  the  state  of  program  verification  than  on  the  inherent  complexity  of 
the  code.  Still,  increasing  the  functionality  increases  the  difficulty  of 
verification  substantially.  The  experience  gained  in  proving  the  simple 
prototype  labeler  leads  us  to  believe  that  our  subsequent  efforts  can  be 
more  ambitious.  However,  we  arc  not  discounting  the  size  of  the  effort 
involved 

A  labeler  might  take  advantage  of  the  special  functionality  of  the 
intended  output  device.  However,  "smart"  devices  arc  likely  to  afford 
increased  opportunities  for  covert  channel  exploitation.  An  oulpuL  device 
may  have  internal  parameter  resettable  via  some  input  sequence  of 
control  characters,  for  example.  Resetting  page  size  may  vitiate  labeling 
constraints  by  placing  labels  outride  of  physical  page  boundaries.  'To 
avoid  this  interference  from  internal  device  parameters,  certain  sequences 
of  characters  would  be  disallowed  as  output  from  the  labeler;  it  is  much 
easier  to  limit  the  set  of  acceptable  characters  than  to  eliminate  specific 
undesirable  sequences  of  characters.  Our  approach  lias  been  to  limit  (by' 
programming  fiat)  the  range  of  device  functionality  exploitable  by  the 
user  by  removing  all  control  characters.  An  alternative,  and  more  likely, 
approach  would  be  to  insist  that  only  devices  of  limited  functionality  be 
used  in  a  secure  environment  thus  eliminating  the  possibilities  for  abuse. 

The  prototype  labeler  is  trusted  only  insofar  as  its  correct 
functioning  is  crucial  to  the  maintenance  of  system  security,  not  in  any 
special  privilege  it  may  exercise  to  violate  constraints  against  information 
flow.  Use  of  type  enforcement  limits  the  amount  of  software  which  must 
be  trusted  in  that  way,  and  permits  the  verification  effort  to  concentrate 
on  the  functionality  of  trusted  modules.  The  proofs  of  the  integrity  of  the 
dar.a  flows  between  modules  are  trivial  since  they  follow  from  the  generic 
proof  or  the  type  enforcement  mechanism. 

The  use  of  the  type  enforcement  mechanism  has  proved  a  powerful 
approach  to  maintaining  the  integrity  of  labeled  text  It  allows  us  to 
provide  an  assured  pipeline  for  moving  unlabclcd  user  text  through  the 
labeler  to  the  line  printer  without  the  danger  that  the  labels  could  be 
altered  at  any  intermediate  point.  Having  the  type  enforcement 
mechanism  as  an  integral  pari  of  the  security  apparatus  permits  us  to 
construct  such  an  assured  pipeline  in  any  similai  circumstances  rather 
than  to  construct  an  ad  hoc  solution  for  each  new  circumstance. 
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APPENDIX:  GYPSY  CODE  FOR  THE  LABELER 


scope  labe ] er  LP  = 
begin 


lemma  PACEJ’ARAMETEHSPOSITIVE  = 
loglcal_page_length  ge  1 
k  logical_pag«_vidth  ge  l; 

function  LF:  character  =■ 
begin 

exit  (result  =■  scale  (10.  character)); 
result  -=  scale  I’lO,  character), 
eno;  <LF> 

function  FF.  character  - 
begin 

exit  (result  -  scale  (12.  character)): 
result  :=  scale  (12,  character) ; 
end:  {FF> 

function  CR.  character  = 
begin 

exit  (result  =  scale  (13.  character)), 
result  :=  scale  (13,  character) . 
end;  <CR> 

function  SP:  character  = 
begin 

exit  (result  -  scale  (32,  character)); 
result  =  scale  (32,  character) . 
end;  <SP> 

function  PRINT1NG_CHARACTER  (c:  character)-  boolean 
begin 

exit  (result  Iff  c  in  (SP..*")); 
result  :=  (c  In  (SP..1-)): 
end:  {printlng_character> 

lemma  SP_TN_PRINTABLE_SET  = 
sp  in  [sp.  .  “}  . 

lemma  CARRI AGE_CONTROL_NONPR I NT I NG  = 
not  prlntlng_character  (CR) 
k  not  prlntlng_character  (LF) 
k  not  prlntingcharacter  (FF) ; 

function  ^LINE  FEEDS  (n:  integer):  text  = 
begin 

entry  n  ge  0: 
exit  (result  = 

(If  n  ^  o 

then  null  (text) 
else  N  linefeeds  (n-1)  <.  LF 
fl>). 

var  1 :  Integer  :=  n. 
result  :=  null (text) . 
loop 

if  i  =  0  then  leave  end; 
result  .=  result  <-  LF; 

1  :=  1  -  1. 
end,  (loop) 
and;  (n  linefeeds) 

function  ;/_8LANKS  (n:  integer)  text  = 
begin 

entry  n  ge  0. 
exit  (result  = 

Of  n  =  0 

then  null  (text) 
else  N_blanXs  (n-l)  <:  SP 
fl)). 

var  1  Integer  - =  n ; 
result  =  null (text) . 
loop 

If  1  -  0  then  le*ve  end; 
result  .=  result  SP; 

1  .*  1  -  1, 
end;  (loop) 
end;  (n  blanks) 


type  LEVEL  TYPE  :  pending. 

type  TEXT  -  sequence  of  character. 

type  LINE  -  sequence  (logical  page  width)  of  character. 
Type  PAGF.  =  sequence  (logical  page  length)  of  line, 
type  PAGESEQ  =  sequence  of  page, 
const  LOGICAL_PAGF._LENGTH  Integer  -  pending, 

const  LOGICAL _PAGE_W!DTH  Integer  =  pending. 


function  N_NULL_LINES  (n  integer) •  page  - 
begin 

entry  n  ge  0 . 
exit  (result  = 

(if  n  =  0 

then  null  (page) 

else  Nnull  lit.es  (n-l)  <:  null  (line) 
fl)): 

var  i  Integer  ; =  n , 
result  .=  null (page), 
loop 

if  1  =  0  then  leave  end. 
result  =  result  <  null(llno). 

1  =1-1. 
end.  (loop) 
vid.  <n  nail  lines) 


procedure  PAQIHaTOR  (insaq:  text; 

?*r  purgetxt:  text; 
tar  pages:  pageseq)  s 

begin 

exit  purg«txb  -  purg*_text  (insaq) 

*  corract_page_sequance  (pogas) ; 
r*r  curr»at^colu»n_positlon :  integer  :=  1; 
var  curran t_rov_posi tion :  integer  1; 

▼ar  current_input_position :  luteger  l; 
tar  curreatjjoge :  page  -  null (page), 
tar  currantllne-  lint  =  null (lint) ; 
p*£««  :*  iull  (psgesaq); 
purgetxt  :»  null  (tsxt); 
loop 
assart 

purgetxt 

«  purge_text  (insaqti  ..  curr*nt_input_position  -  0) 
ft  corract_poge_8equenca  (pa^aa) 

ft  corract_parti»l_p»g*  (curr-mt  pag».  curr*nt_line . 

curr-mt^row^posl  tion, 
curreofc<_calusn_po*itloft) 

ft  six*  (currant_poge)  *  curr-mt._row_posltJ.on  -  1 
ft  six*  (currant  line)  =  currsnt_coluan  position  -  l 
ft  curr*nt_row_ position  in  [1 . . loglc*l_paga_length] 
ft  eurreut^eolusa  position  in  Cl • • loglcal_pag«_vidth] ; 

If  currsnt^loput  position  =  uiza  (insaq)  ♦  l 
than  leave 
•  nd ; 

if  iesaq  (curreut_input_posi tiou)  =  OR  than 
curr*Dt_llna  :s  yjll  (line)  ; 
currsnt_colu»n_pos1 tion  s  i; 

tls« 

if  lacsq  (current_inputj>osltion)  =  FK  than 
curreutpage  :  =  currsntpage  <:  current_llns 
•  N_nuli_Unes  (logical_p*ge_leogth 

-  current__rov_position) ; 
pages  :»  pages  <:  currant_page; 
currsntpaga  :=  null (page); 

curreotrov  position  :=»  1; 
currentllna  :«=  nuU(lloe), 
currsot_coluan_positlct  :=  1; 
else 

If  Ooseq  (current^  lnput_posltioti)  s  LF)  thsn 
current  pagt  ,-s  currsntpage  <:  currsnt_lins; 
if  ourreat_rovj>csltion  =  logical_paga_Tength 
then 

pages  :=  popes  <:  currantpage ; 
current  page  :=  null(piige); 
current  row^posltlon  :  =  i; 

alas 

current_rovj>osition 

currsnt_rov_ position  ♦  1; 

ond ; 

current^llne  .*  oulUUni) 

«  K_bisnJcs  (ourrsnt_coiuan_position  -  l) : 

•  1st 

if  printlng_  chsracter 

(insaq  (current^ lnput_posltion))  than 
purgvtxt  :=  purgatxt 

<:  instq  (current_lnput_posl tion) . 
currant_)ina  :*  currant  line 

<:  insaq  (current_lnput_posl tion) ; 
If  currantcolyan^posltion 
-  logical_pag#  width 
than 

current_pege  .=  current_paga 

<:  cum nt_llne ; 
curr«nt_llna  ■  =  nullQina); 
curran t_coluan_po*l tion  :«  j. 

If  currant  row  position 
=  loglcal_psgt_lsngth 
than 

pagas  :=  pages  <:  currsntpaga . 
currsnt_paga  :=  null(pago); 
current_rov_pocltlon  .=1. 

alst 

curr«nt_rov_positlon 

:=  currant_row_posltion  +  l: 

and : 

•  Isa 

curran t_colusn  position 

.=  currant_colusn_poeltlon  *  1. 

and:  (1!) 

•ad;  {lf> 
and;  <lf> 
sod,  <lf> 
and;  <lf> 

curraot_lnput_position  =  currant  input.  posi tion  *■  1; 
and,  <loop> 

currant  page  '=  current  page  <  currentlius 
t  Nnulllinas  (logic*l_pags_l#ngth 

-  current  rovposltlon) ; 


pages  :=  pugs*  <:  currentpaga ; 

•nd;  (paginutor) 

functiou  PURGE_TEXT  (lnssq:  tsxt) :  tsxt  = 
bigin 

sxlt  (ossuto#  rasult  - 

(if  lussq  =  null(tsxt) 
than  null(tsxt) 

•  1st 

(If  printing_charsctar  (last(insaq)) 
than  purge_ttxt  (nonlast  (Insaq)) 

< :  last(lnsaq) 

alsa  purg«_t«xt  (nonlast  (Insaq)) 
fi) 

fi)) . 

and;  fpurga_taxt> 


function  CORREXTT_LINE  On:  lina):  poolaftn  - 
bagln 

axlt  (assuss  rasult  iff 

(  slza(ln)  la  logical  paga_width 
ft  (all  1 :  intagar, 

l  in  [l  .  slxa  (In)) 

->  printing_charactar  (ln[i))))), 
and;  <corract_llna> 


function  CORRECT_PARTIAL_LINE  (In:  lina; 

currant_col_posltion : 


'  boolaan  = 


in  t«gai) 


bagln 

axil  (aseuna  rasult  iff 

(  currtnt_col_po«ltl.on  in  [l  .  logical_pags_vidthJ 
ft  corract_llna  (In))); 

•nd;  <corrsct_partial_lins> 


function  COKRECTPAGE  (pg:  paga) :  boolaan  = 
bagln 

sxlt  (assuat  rasult  iff 

(  sixa(pg)  =  loglcal_paga_langth 
ft  (all  1:  Intagar. 

1  in  (1  .  Siza(pg)) 

->  corrsct_lina  (pg[l])))>; 
•nd;  {corr#ct_pagt> 


function  COP.R!>CT_PAnTlAL  PAGE  (currant_pagt :  paga; 

currant_lina  lina; 

curran t_rov_poci tion :  intagtr; 

currant_col_position :  intagar) 

boolaan  = 

begin 

exit  Cassuu*  rasult  iff 

(  corract_partlal_line  (currant^line . 

currint_co]_position) 

ft  currant_rov_positlon  in  [l .  logicalpagaltngth] 
ft  current^row  position 

=  xt ze (  current^page  •  Isuq:  currant_llne) ) 
ft  (all  J  .  intagar, 

1  in  (i  ..  size (currentpaga) 3 
->  corractllna  (curran t_page Cl] )>)) ; 
and;  <correct_partial  paga) 


function  CORRECT_PAQE_SEqUENCE  (pages:  pagasaq) :  boolaan  » 
bagln 

axlt  (assusa  rasult  iff 

(  pagas  =  null (pagaseq) 
or 

(  corract_ paga  (last  (pugav)) 
ft  corract _pago_saquanca  (not. last  (pages))))); 
and;  <corr*ct  paga  saquance) 


ltfc»a  PURGnABLE_CHARACTER_EXTENSION_LEMHA  (insaq:  tart. 

c:  character)  = 


not  prlnting_charactar  (c) 

->  purga_taxt  (lnseq)  -  purge_taxt  (insaq  <  c). 


lease  NONPURGEABLE_CHARACTaV-EXTENSI°^LEhMA 

printlng_charact«r  (c) 

->  (purga_t»xt  (lnseq)  c)  =  purge_taxt 

lesaa  SIZE  N_NULL_L I N ES  (n :  Integer)  - 

n  ga  0 

-> 

•iza(n_null_llnes  (n))  =  n; 

lessa  SIZE_N_BLANKS  (n  .  integer^  - 
n  ga  0 

-> 

size  (n  blanks  (n))  =  n; 


(lnseq  text, 
c:  character)  - 

(Insaq  < :  c) ; 
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lemma.  N  DLANKS  ALL  BLANK  (a.  1  lntogor)  - 
(n  go  0  A  1  In  [1  n]) 

->  nblanXs(i)  [l]  =  sp. 

lemma.  N  h'JI  L  LINES  ALL_NULl  (n .  1  integer)  - 
(  1  in  Tl  n]  ) 

-> 

n  null  1 1 n a s ( n ) [ l ]  =  nuil  (line)  . 

lemma  LINE  INDEX  LEHMA1  Cln.  wore  lino,  i  in  Lege  i  )  - 
1  in  (l  size  Cln))  ->  (In  3  rr.cre)[l]  -  ln(l). 

lemma  LINE_INDEX  LEMMA2  (In.  more  *  ilr.e;  i  .  integer)  = 
1  in  [sl2e(ln)+]  sl?.e(ln)  *size  (more)) 

-> 

(In  ®  moreHi]  =  more  [l -size (In) ]  . 


loop 

assart  correctly_labeled  (outseq.  lvl) 

A  label  =  assoclated_label  (lvl) 

A  purgetxt  =  purge_toxt  (lnseq) 

A  correct_pago_sequence  (pages)  . 
if  pages  =  null  (pagosoq)  then  leave,  end; 
outseq  .=  labeled_pago  (last  (pagos) .  labol)  3  outsoq, 
pages  -=  noulast  (pages)  . 
end.  (loop) 
end ;  (labeler) 

function  ASSOCIATEDLABEL  (lvl;  leveltype).  text  = 
bogln 

exit  (assume  size  (result)  le  loglcalpagevldth) . 
pending; 

end.  (associatedlabel) 


lemma  TEXT_INDEX_LEMMA1  (txt. more  text;  l  lntogor)  = 

1  in  [1 . -6lze7txO]  ->  (txt  a  more)  (l J  -  txt(l). 

lemma  TEXT_INDEX_LEMKA2  (txt, more  text,  1  .integer)  = 
l  In  [size(txt)*l  slze(txt)-*sl7.e(x.ore)] 

-> 

(txt  ®  more)  ll)  =  more  [l  -  slz-  (txt)  ) 

lemma  SEQUENCER  NDEX_LEMMA1  (ppg.  more:  page. 

l  Integer)  - 

1  in  [1.  size (ppg)] 

(ppg  e  more) (i)  =  ppgll) : 

lemma  SEQUENCE.  I NDEX_LEMMA2  (ppg.  more  page. 

1  integer)  = 

1  In  (size(ppg)+l .  . size  (ppg) 'Slze(tr.ore)] 

-> 

(ppg  e  more) (l)  =  more [i-SLze (ppg) ] . 

lemma  SEQUENCE^ ELEMENT_LEmA  (elom  line,  ppg  page)  = 
elem  m  ppg 
iff 

some  l  integer.  1  in  tl ■  size  (ppg) J  k 
elem  -  ppg[l] ; 

lemma  EXTEND  TO  PAGE  (currentpago  page. 

curr«nt_l  l.ie  line, 
curren t_row_posl tion . 

current  column_positlon  .  integer)  = 
correct  partialpaga  (current  pago .  curren t_l J n e . 

current_rov_posl tlon . 
current_colufsn_posltion) 

->  correct  page  (  current_page  <  currentline 

%  n_null_lines  (  logical  pagel ength 

-  current_rov_posltion) ) . 

lemma  ADP_CORRF.CT_PAGE  (pages  pagesoq. 

curi ent  page  .  page, 
current) lno  line. 
current_row_posltlon . 

current_column_pcsi tlon  Integer)  = 
correct_pago_sequence  (pages) 

A  correctpartialpage  (currentpago .  current_ 1 l n« . 

currentrov  position, 
curren tcolumnposltl on) 

• >  correctpage  sequence 

(  pages  <9  [seq  current  page  3  [seq  current  line] 
a  n  null_line3  (logical  page_length 

■■  cumnt_rov_posl  t ion)  ] )  ; 

lemma  EXTEND_LAST_L1NE  (current  ll ne  line. 

current  page.  p-<;o. 
pages  pageseq . 
c  character)  = 
correct  page  sequence 

(pages  <•  (  current  pago  <.  -.current  line) ) ) 
k  prlntlng_character  (c) 

k  size  (current  line)  ♦  1  le  logical  page  v*.  1th 
->  correct_page_jequencn 

(pages  <  (curren t  page  <  (current me  <  ^)))- 

procedure  LABELER  (lnseq  toxt. 

var  purgetxt  text, 
var  outseq  text. 

1  v )  level  typo) 

begl  n 

exit  purget.xt  -  puige  text  (lnseq) 

k  correctly  labeled  (outsoq.  lvl). 
var  pages,  pageseq 
var  label  toxt. 

label  -  assoc iatadiabel  (lvl). 
paglnator  (lnseq.  peigetxt.  pag«-s) . 
outseq  null (text) . 


function  LABEL ED_PAGE  (pg-  page;  label:  text):  toxt  = 
begin 

entry  corractpage  (pg) , 

exit  corroctly_labeled_page  (result,  label); 
var  l .  Integer  =  0, 

result  =  [soq  FF.  LF.  CR]  a  label  £  [soq:  LF.  CR)  ; 
loop 

assort  correctly_labe led_parti alpage 

(result,  labol.  1) 

k  correctpage  (pg) 

A  1  in  to. . logical _pago_longth) , 

If  (1  =  logical  pagelength)  then  leave,  and; 
result  .  ~  result  @  pg(l+l)  @  (soq.  LF.  CR]  . 

1  :=  1  ♦  1  . 
end;  (loop) 

result  result  3  [s9q  LF.  CR] 

@  l?bel  ®  [seq:  LF.  CR]  . 

end;  < 1  aba  1 ed^pago) 


function  CURREC1LY  LABELED  (outseq  text. 

lvl  level  typo'  boolean  = 

begin 

exit  (assume  result  iff 

(if  (outseq  =  null(text)) 
then  true 
else 

(some  pg .  text,  some  outseq2.  text, 

(  (outseq  =  pg  6  outseq2  ) 

A  correctiylaboled  page 

(pg.  associated  label  (lvl)))) 

fi>)  . 

end;  (correctly^labeled) 

function  CORRECTLY_LABELLD_PACE  (pg.  text, 

label,  text)  boolean  = 

bogln 

exit  (assume  result  Iff 

(some  body  text. 

(  (pg  -  [seq  KF.  LF .  CR]  Q  labol 
@  [soq  LF.  CR) 

3  body  @  (soq-  LF.  CR]  @  label 
@  [seq  LF.  CR]) 

A  corroctpago  body 

(body,  logicalpagolength)))) , 
end.  (correctly_labelod_pago) 


function  CORRECTLY  LABELED  PARTIAL  PAGE  (outseq  text. 

label  text, 
i  lntogor) 

.  bowlean  = 

begin 

exit  (assume  result  iff 

(some  body  text. 

(  (outseq  -  [soq  FF  ,  Li-  ,  v. *< i  <&  iaooi 

6  (seq  LF.  ::)  8  body) 
A  correctpagebody  (body.  l)))). 
end,  (correctl y_laboled_pagc) 


function  CORRECTPAGE  CODY  (body  text,  pageslzo  lntogor) 
boolean  - 

bogln 

exit  (assume  result  iff 
(If  pageslzo  -  o 
then  true 
else 

(sonc  in  text,  some  tcd/2  text. 

(  (body  tody  2  ‘  In  <»  l  seq  l.F.  CR]) 
k  co i i  in  t  pago  body 

(body'*:.  pagoj-lzo  i) 

A  ttjr.ee  t  line  (In))) 

fl)). 

end.  (correct  page  body) 


()U 


e nd .  (scopu ) 
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ABSTRACT 

A  number  of  hardware  devices  Intended  to 
Improve  dial-up  communications  secur  Ity  have 
recently  been  Introduced  to  the  commercial 
market.  These  devices  can  be  separated  for 
discussion  Into  six  major  groups,  according 
to  their  primary  protection  objective.  The 
six  groups  are:  host  port  protection 

devices,  user  terminal  security  modems,  user 
authentication  devices,  terminal  identifica¬ 
tion  devices,  line  encryption  devices,  and 
message  authentication  devices. 

Many  claims  have  been  made  about  the 
degree  of  protection  afforded  by  these 
mechanisms.  In  contrast,  there  are  persis¬ 
tent  rumors  from  the  "hacker  underground" 
that  the  security  of  some  of  these  devices 
can  be  broken.  Also,  several  problems  have 
been  identified  In  administering  this  family 
of  devices,  some  of  them  economic  or  practi¬ 
cal  and  others  directly  related  1o  security. 
This  paper  reviews  the  classes  of  devices 
available,  describes  their  basic  characte¬ 
ristics  via  examples,  discusses  typical 
security  flaws  and  Implementation  weaknesses, 
and  recommends  a  series  of  approaches  to 
overcome  these  problems. 

Almost  every  computer  of  any  size  has  one 
or  more  ports  which  are  connected  via  modems 
to  the  public  telephone  system  (POTS).  it 
has  become  a  popular  hobby  of  teenagers  and 
others  to  identify  these  computers  and 
explore  them  in  various  ways,  some  of  which 
are  disruptive  fo  business  operations.  In 
recent  years,  there  have  been  growing 
Indications  that  less  savory  individuals, 
such  as  spies  and  criminals,  are  using  the 
same  techniques  as  "hackers",  penetrating 
computer  systems  In  order  to  steal  valuable 
Information  or  to  defraud  organizations. 
This  paper  makes  no  distinction  of  motives, 
ref  err  I nc  to  all  Instances  of  attempted  or 
actual  access  by  unauthorized  persons  as 
"penetrations"  and  the  persons  themselves  as 
"intruders". 

To  counter  this  threat,  good  access 
control  security  Is  now  mandatory  for  a  n  y 
computer  sysfem  connected  to  POTS.  In  mosl 
cases,  the  computer's  operating  system  can 
provide  an  adequate  level  of  access  control 
If  Ms  security-  related  featuros  are  used 
roper  I  y ,  However,  many  smaller  operating 
systems  do  not  provide  these  features,  and 
many  more  systems  are  improperly  administered 
to  tile  extent  that  severe  weaknesses  exist. 
If  this  urity  Is  not  available  through  use 

of  the  computer  system's  own  capabilities, 
t  h  o  n  s  p  e  c I  a  I  I  z  e  d  hardware  security  devices 
may  bo  used  to  augment  or  supp  1  ant  t  ho 


security  features  and  provide  the  necessary 
level  of  protection. 

These  hardware  devices  used  for  dial-up 
security  are  a  mixed  blessing.  Technical 
weaknesses  In  the  design  and  implementation 
of  some  of  these  products  may  exist  which  In 
themselves  offer  the  Intruder  an  avenue  of 
approach,  effectively  negating  their  useful¬ 
ness.  In  addition,  there  often  are  adminis¬ 
trative  drawbacks  to  the  use  of  these 
security  devices.  In  the  form  of  unjustifi¬ 
able  extra  costs  and  administrative  burdens. 
Potential  and  current  users  of  the  dial-up 
security  devices  need  to  examine  these 
weaknesses  and  drawbacks  carefully  so  that 
security  and  effectiveness  may  be  Improved  by 
correct  usage  o*  the  devices. 

NATURE  QF  THE  THREAT 

There  Is  no  doubt  of  the  growing  penetra¬ 
tion  threat  to  computers  with  dial-up  access 
to  the  POTS.  A  number  of  factors  Increase 
that  threat  to  the  point  where  If  must  be 
taken  seriously  but  without  over- emphasis. 

Q-P.8-DJia_S.S__.Qi QJjllrclliL  ( TLQ-I £1..  jtldLW  JJJ.k..  For 

several  years,  it  has  been  possible  for 
anyone  with  access  to  a  telephone  connected 
to  POTS  to  dial  directly  almosl  anyone  else 
with  the  same  access  In  this  country  and  most- 
other  countries  of  the  free  world.  The  only 
Impediment  to  this  access  Is  know  ledge  of  the 
target's  telephone  number.  A  very  small 
number  of  protective  measures  ore  available 
In  some  locations  for  POTS,  but  these  ate 
costly  and  not  well  known.  These  measures 
are:  unlisted  numbers,  automatic  call- 

tracing,  and  limited  call-in  list.  In 
general,  aiLyQ.o.e  with  access  to  a  telephone 
and  a  modem- eg u I p po d  terminal  anywhere  In  the 
world  has  the  potential  to  become  a  user  of 
any  computer  with  dial-up  access  In  the 
world.  It  Is  known  that  some  of  the  most 
sophisticated  penetration  attempts  on 
computers  In  the  United  Slates  have  come  from 
Europe  and  the  Middle  East. 

Anyone  witli  a  minimal  grasp  of  present 
computer  technology  can  readily  understand 
that  no  complicated  equipment  Is  needed  for 
dial-up  penetration.  Terminal  emulation 
software  Is  readily  avo liable  for  all 
personal  computers,  Including  those  In  the 
Inexpensive  hobby  class.  Likewise,  modoms 
can  bo  obtained  at  any  computer  or  electron¬ 
ics  store,  with  starting  prices  at  less  than 
$100.  One  of  the  most  commonly  used  penetra¬ 
tion  Instruments  Is  the  Commodore  64,  a  hobby 
computer  for  which  extremely  sophisticated 
"hacker"  software  has  boon  wr liter  and  Is 
available  on  pirate  bulletin  boards. 
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Intruder  Understand  1  OlLQjLXaitlkaftJ-ttax.  Modern 

hobbyists  have  a  grasp  of  computer  and 
communications  technology  that  Is  little 
short  of  awesome  In  some  cases.  It  must  be 
accepted  as  a  guiding  rule  thal  Intruders,  bo 
they  "hackers"  or  more  sorlous  criminals, 
know  at  toast  as  much  about  technology  as 
anyone  within  the  tar  gel  organisation.  ll>c 
only  facts  that  they  mlyiit  not  know  are  lire 
specific  details  of  system  implementation  In 
a  particular  organization.  It  a  p  poors  thal 
disgruntled  employees  or  other  Insiders  have 
provided  erven  I  h  i  s  Information  to  pirate 
bulletin  boards  and  other  underground 
sources. 

Sharing  of  P  oil  fltra.1  I  on  luittrJUji.tl.Qn.*  The 

pirate  bulletin  boards  are  an  Indication  that 
Intruders  like  lo  share  information  and  bray 
about  their  exploits.  Often,  this  Is  the 
primary  avenue  for  others  to  obtain  a  goorl 
education  about  the  technology  and  security 
protection  mol  hods  commonly  us"d.  This 
widespread  sharing  of  information  signifi¬ 
cant  1  y  I  n  c  r  o  a  s  o  s  the  level  of  intrudoi 
threat. 

fiAIURE  Ui.  YULfiLKAd  LLil  iLS 

There  are  some  common  vulnerabilities  in 
the  oporaflon  or  administration  of  computer- 
systems  which  make  it  rnu c h  on s  1  o r  tor"  Intru¬ 
ders  lo  gain  telephone  access.  It  is  a  sad 
commentary  thal  by  far  the  gr palest  majority 
of  known  penetrations  have  occurred  by  simple 
exploitation  of  prevalent  administrative 
weaknesses,  and  not  from  any  technical 
sophistication  on  the  part  of  the  Intrudoi. 

USER  I  D/fasswor  d  Adm  l-UiJLtr-aiioiL.  1  h  «  typical 

penQtrdtlrn  a  I  t  o  rn  p  1  slat  t  s  out  ay  using 
USERIOs  and  passwords  that  Intruders  know  to 
be  commonly  usod  Irr  poorly  s  Cv  ur  o  d  systems  . 
Pirate  bulletin  boards  of  1  on  provide  list:,  of 
1  h  o  ni  for  novices.  The  most  notorious 
examples  include  the  (cl  lowing. 

•  Any  v.ua(ior:-auCjll  Ip.d  USERID  or  password 

(  tho  most  common  .mil  ofroc+lve  pencil  alien 
avenue  of  all,  b. cause  I  hose  typically  carry 
"super-user "  pi  i v i  I n go s  )  . 

•  Common  first  or  Iasi  aUKQi  ( permit. j- 
tors  often  o  b I  a  I  »  organization  telephone 
b ook s  a  n  d  try  likely  names). 

•  Any  common  ilttllJlfLV. IuILQjQ.  ns  pec  ial  ly 
conrpulDi'-re  I  a  I  o d  . 

•  USERID  “  password. 

•  Qn.U_Qr._i.WjD  letters  or  numbers. 

•  Any  icer.d  In  a  dictionary  I  Inti  udors 

are  now  harnessing  un-l  inn  d  I  c  t  I  o  na  r  I  (is  o  r 
spoiling  c  li  u  c.  kcr  '  1  o  1  li  u  I  r  p  e  noli  a  I  I  o  n 

software). 

2.4- hour.  Ulal  -Up  . Ancona  ibl  1 1  ty_.  it  I  ••  romaik- 

a  b  I  o  how  many  c  om  p  u  I  o  r  s  y  s  I  o  in  s  of  all  s  I  /  o  s 
p  o  i  rn  I  t  dial-up  a  c  c  u  s  s  .it  all  hours,  u  v  o  n 
f  lie  u  rj  h  It  may  be  mil  I  k  u  I  y  that  any  I  o  g  I  H  in  a  1  o 
use's  may  bu  seek  I  rig  across  out  si  do  ol  normal 
weekday  buslnc-s  hours.  Ibis  Is  coupled  w  i  I  ti 
the  fart  I  li  a  1  mosl  piniDti  ,il  Inn  nl  lump  b.  occur 
dur  I  nij  non- b  u  s  I  nos  .  hours.  bl  Inn,  Iho  romody 


is  ex+remely  simple:  turn  oft  or  disconnect 

modems  when  not  actually  noodeu. 

Dperat  I  rig _ System  Woaltnessas^  Many  operating 

systems  either  do  not  have  many  security 
features  or,  morn  typically,  provide  the 
features  but  make  thorn  optional  to  the  using 
organization.  Often,  Iho  features  are  viewed 
by'  system  software  engineers  as  unnecessary 
or  as  causing  reductions  In  system 
performance  or  easo  of  use.  The  latter  may 
be  true,  but  the  threat  from  intruders  Is 
growing  to  such  a  dogree  that  It  Is  almost 
Irresponsible  to  operate  a  System  with  dial¬ 
up  access  thal  does  nol  havo  demonstrably 
effective  access  control. 


BASIC  DIAL-UP  _S.tCliRm _RLOU_LE£M£liiS 

In  ordor  lo  reduce  the  effectiveness  of 
Intruder  penelralion  via  lire  telephone 
system,  there  are  four  basic  requirements 
which  should  be  mef.  typical  mainframe  and 
minicomputer  operating  systems,  when  proporly 
usod,  may  be  able  vo  take  coni  of  all  or  part 
of  the  problem,  but  no  unador  net!  micro¬ 
computer  operating  system  can  do  so.  If 
lliese  requirements  are  not  adequately  met  by 
the  host  11  so  I  I,  then  add-on  equipment  may  bu 
needed  to  supplement  Its  protection. 

U.fi-Qr.  ..Ldo.n.1.1.  f  Lc.ii.ilou  .and  AjiilLauiI.LjatiQ.iu 

This  Is  the  koy stone  of  all  access  control 
security.  A  well  administered  USERID  and 
password  process  Is  very  Important  f ur 
computers  with  dial-up  access,  because  It  Is 
tho  first  access  control  mocha n Ism  typically 
uncouiit.'i  tul  as  tho  user  on  tors  a  system. 
When  this  capability  Is  weak  or  nonexistent 
tor  any  i  o  a  s  o  n ,  a  variety  of  e  x 1 e  r  n  a  I 
hardware  mechanisms  (.an  provide  or  augment 
I  his  capability. 

ILv  CJi.ri±.y_.JE.YP.nL..i.Qaai.iiaw  M'  Is  r'0w  an 
accepted  security  principle  thal  all  d I  a  I  -  up 
communications  activity  between  host  a  rut  user 
ought  to  bo  monitored  In  ordor  lo  uncover 
Intrusion  a  1 1 om p 1 s ,  or  worse,  successes.  lor 
larger  computers,  this  can  be  done  routinely 
by  lire  system  journal.  Several  add-on 
external  devices  can  perform  Ibis  I  unction  us 
pari  ul  a  dial-up  us or  access  control  strat¬ 
egy  . 

Li  II)  l  II  ItuHlQ  ATlucKi..  If  l  he  In  1  ruder  does 
not  know  the  correct  access  codes,  Ihon  he 
nus I  make  many  qucss'ng  attempts.  In  some 
cases,  this  Is  done  by  tho  Intruder  's  compu¬ 
te  t  .  w  h  I  t  li  runs  a  n r  ocjr  am  1li.il  go  n  n r  a  I  n  s  a  n  d 

tries  o  series  of  pa  s s w  o r d s  o  n  u  oft  o  r 
another.  Any  in  o  c  h  a  n  i  ■ .  m  s  that  limit  Iho 
number  or  speed  of  r  e  p  e  I  I  I  I  v  o  user  s I y  n - o  n 
a  1  I  e  m  p 1 s  pur  dial-up  connection  can  h  e  I  p 
counter  this  typo  of  attack. 


CoaCjfija_l.Mfiilt  Oi  juf  yiJKLUl  I«R.  If  Iho  Informo- 
llon  whli.h  Is  ci<  ;:i;s  s  I  b  I  o  v  I  <i  (J  In  I  -up  connoc- 
t  Ion  i  i,  vory  to  n  f  1  do  n  t  I  <j  I  or  l>  u  sc 0  p  I  I  b  I  0  to 

I  r  oud.  Ihon  it  nuiy  nuod  to  bo  pr  o+  ec:  t  o  0  from 

d  I  t>  c  losur  o  n  r  t  <)  m  p  o  r  I  r>  fj  v  I  o  who  t  o  p  s  or 
other  forms  o  f  I  r>  I  or  cop  lion,  Any  rr  octi  t)  n  I  :»ins 
or  sat  I  will  <!  thnt  c'nc.iypt  Iho  I  n  f  or  in.]  f  1  on  on 

tho  line*  help  prnynnt  I  his  cond  II  i  on  , 


In  v  a  r  I  o 
fund  I  uni 


wdys  to  perform  their  security 


Tc  protect  d : j I -up  communications  with 
hardware  security  devices,  the  communications 
link  itself  is  secured  independently, 
external  to  the  computer  hardware  or  soft¬ 
ware.  Several  types  of  devices  are  available 
that  apply  one  or  more  of  the  dial-up 
protect icn  functions  described  above  tc  the 
comm  urinations  I  I  r.  k  . 


The  p  r  I  rri  ary  a  J  yardage  in  u  s  i  ruj  hardware 
security  devices  is  that  it  reduces  the 
degree  of  dependence  on  olher  software  or 
procedural  security  mechanisms  in  the  system. 
Many  of  those  mechanisms  may  not  be  strong 
enough  or  may  net  u-'Cn  be  readily  available 
for  a  specific  computer  system.  There  .re 
two  other  notable  benefils  to  be  gained  by 
applying  n  ci  r  d  w  a  r  e  protection  to  the  communi¬ 
cations  link. 

Separation  Qf  Function.  In  Ubiiig  haronar  e 
secui  ity  devices,  sop.'r  al  ion  of  fund  ion  is 
gained  by : 

•  txterna  I  I  z  at  I  on  of  a  scl  of  socur  i  ty 
functions!  outride  1  he  machine,  physical  1  y  <i no 
logically  separated  from  the  ho:»l. 

•  Kernel  I zn  !on  of  u  portion  of  the 
security  function-  into  a  single  dedicated 
net h  c  n i b  m  for  reduced  and  controlled  access 
via  i  jrrmi  ii  [i  I  ca  1  ions. 

ftd.rf.LM  o  n  a  1 .  _  L  it y_Q_r  x  _.o.f  _ Px.Q.ta_ci-l q n.  Ma  r  o.  a  r  o 
security  devices  on  f  h  e  system's  t  omm  u  n  i  <.  a  - 
Tie  ns  links  provide  formal  prolection  of  the 
network  Itself.  Mo ,  hard  w  a  I  e  prof  i  cl  ion  is 
designed  1  o  control  authorization  to  a  single 
s  y  s 1 u m  object,  the  communications  port. 
Olher  soffwa'o  and  procedural  security 
mechanisms  s  h  o  u I  d  s  t  i  1  I  be  used  to  reduce 
logical  exposure  to  the  remainder  of  I  lie 
sy  s 1  cm . 

IHl  iiX-.IYFLi._Qt  HARUWAKL 

in  protecting  any  set  of  dial-up  communi¬ 
cations  ports,  two  basic  approaches  <  ,j n  be 
taken  w  h  i  c.  h  involve  adding  hardware  pro  tec  1- 
i  nil  devices  to  1  Ihi  dial-up  circuit.  I  lur  -.  i 
approaches  arc;  referred  lo  as  fhu  "o  n  c  -  c  n  a  " 
ano  "  t  w  o -  e  n d "  solutions,  cfe  pe n d  i  ntj  upon  the 
placement  and  configuration  of  1  h  c;  protective 
h  a  i  d  w  a  r  o  . 

Iiu3_  "One- end _ Luiu-tlsn."  Iks.  _Iy.p.es..  this 

solution  provider  a  ^cparijle  on  t  h  c 

l um m u  n i c a  1  i o n  b  link  I  1 <  c I  f ,  by  using  hardware 
t  <j  protect  only  one  end  of  I  ho  conmiunic  ri  ions 
link.  Two  types  of  c  u  v  i  c  u  *.  «  j  i  o  dvdi  lubl  e, 

onu  fur  i  n  s  t  i !  1  9  1  i  on  on  the  hubf  computer  .utd 
t  h  o  other  on  the  ;j:,or  1  r,  terminal.  T h  u  s o 
dev  Icos  per  form  a  basic  user  on  I  liun  f  i  (.n  i  i  on 
screening  function,  normally  without  t  h  e 
requirement  for  user*.  1  o  obtain  a  ■■  y  extra 
equipment. 

The.  "  lso.-e.iui  aoLutlvii"  .---  f..oju  ...lyftfii,.  Hor  « 

security  Is  gained  by  using  a  ma  t  c  fi  fit:  -■  n  t  o  i 
h  a r  tl  w  a  -  o  protect  ice  devices  for  U.oiii  ends  o' 
1  h,  c;  dial-up  circuit  (  comp  n f  e  r  a  n  d  I  cm  ...  i  n  u  I  )  . 
liirjse  device-,  can  corr.'nu  r.  i  c. a  t  (■  with  each  offiui 


The  four  types  of  equipment  ore  divided 
up  by  function.  Three  perform  nut  Pent  [ration 
functions,  respectively,  of  the  us  or,  the 
user's  term  Inal  or-  location,  and  the  message 
or  data  iransmilted  via  1  he  circuit.  The 
fourth  type  is  line  encryption,  which 
per  forms  a  conceal  ment  function  on  tiro  trans¬ 
mitted  data,  and  may  also  be  construed  as 
authenticating  the  user  or  originating 
terminal  via  the  process  of  encrypt' on  key 
exchange. 


The  first  group  of  devices  to  be  dis¬ 
cussed  Improves  user  access  control  by 
performinq  a  preliminary  call-screening  or 
authentication  function.  Typically,  such  a 
device  is  total ly  Independent  of  the  compu¬ 
ter.  Devices  in  ttiis  category  are  called 
"one-end  sol u I  ions",  because  they  are  used  on 
only  one  end  of  the  communications  circuit 
between  the  host  and  terminal,  but  not  both. 
Most  version,  of  one-end  protection  devices 
arc  Installed  at  t  h  o  host  c  omp uter  end,  but 
some  newer  multi-function  devices  are 
connected  lo  the  user's  terminal. 

Host  Port  Protection  Devices _ (.PPLs }_»  A  PPD 

is  fitted  t  c  f  h  e  communications  port  of  a 
host  computer,  providing  the  function  of 
a  u  t  h  o  ‘  I  z  i  n  y  user  access  to  fhe  port  Itself, 
prior  to  jnu  in  do  pen  deni  of  the  computer's 
own  access  control  functions.  It  is  specifi¬ 
cally  designed  to  help  control  terminal 
access  wticn  dial-up  c omm u  n  I  ca  1  i  on s  a r e  n-.rsd  , 

Depending  on  design,  a  PPD  may  operate 
between  'Ire  host  and  modem  (digital  side),  or 
ii  may  opeiale  between  modem  and  telephones 
set  (analog  side).  Some  moderns  include  PPD 
functions  in  a  single  unit.  Once  connection 
and  user  validation  lake  place,  1  Ii  ss  P  P  f) 
becomes  passive  In  Ihe  circuit.  The  four- 
primary  foal uros  of  PPDs  are  described  below. 

•  Password  tables.  All  PPDs  require  the 
user  I  o  enter  a  o  p  a  r  a  1  e  a  u  t  h  e  n  1  i  c.  a  t  o  •  or 
password  i  n  o  r  d  (■  r  1  o  access  1 1i  o  c  orr,  p  u  t  til  '  s 
dial-up  ports.  this  sel  of  externa  I  password 
fables  i n oc pen do n 1  of  the  computer's  opera- 
'  i  n  y  s  y  ■■  1  u  rr.  is  the  primary  [it  riled  in  i  given 
by  I5  I’D  s  .  All  of  t  h  o  s  e  devices  I  I  .  r  I  t  I  he 
number  of  s  I  g  n - o  n  a  t 1 e  m  p  t  s  per  telephone 
connection,  in  or 
a  I  tacks. 


repel!  1  I v  e 


•  Call-back  to  Originator.  Most  PPDs  do 
Iio  i  liovo  or  n c*  w d  t  h  i  s  c a p a b  i  I  i  1  y  ,  although 
some  per  sons  erroneously  cal  I  al  I  i-’PiJs  "cal  I- 
back  dovlcs".  fills  feature,  when  present, 
is  used  as  a  second  love  I  of  external  ust:r 
authentication.  A  PHD  w I  I h  call-back  will 
ordinarily  r  e q  u  i  r u  lire  user  to  outer  a  P P 0 
fable  password,  and  then  will  disconnect  t  h  c 
lino.  T  Ii  o  DPI)  then  Identifies  f  h  o  user's 
telephone  number  that  matches  Ihe  password 
and  makes  a  return  cal  I  lo  I  ht,-  user  fur  ho  it 
lorinod  ion. 

•  Hiding  the  Port.  All  I'PPs  have  some 
ability  I  o  "  (.  a  mo  u  f  I  a  g  *j  "  I  1 1  e  <  o  in  pater  ' 
dial-up  pot  Is  so  that  the  <  nmy  ij  I  s-r  cannot  c  c 
Identified  by  an  u  tin  u  I  h  or  I  /  ■:  cl  c  a  I  I  u  r  .  S  urr,  r 


PPDs  located  on  the  11  analog-side"  use  a 
synthesized  human  voice  to  hide  the  modem 
tone  on  initial  connection.  "Digital  side" 
PPDs  send  their  own  screen  displays  via  the 
modem  to  The  user's  terminal  which  masks  the 
kind  of  computer  they  arc  protecting,  vital 
information  needed  by  the  intruder  to  carry 
out  liis  attack. 

•  Attack  Signalling.  Most  PPDs  are  able 
to  provide  s  om  e  form  of  warning  signals  or 
-ocords  of  dial-up  attack.  Some  models  use 
front-panel  display  lights,  others  maintain 
Internal  logs  in  RAM  storage,  and  the  most 
expensive  models  use  the  disk  1  forage  of 
dedicated  personal  computers  to  record  many 
types  of  information  about  communications 
ac  1 1  v  i  t  y  . 

Security  Mo  d  par  s _ for  Users.  Several  now 

devices  are  part  of  the  trend  towards 
Integration  of  security  features  into 
standard  devices.  Control  !ed-ac«  e*»s  "secur  ¬ 
ity  modems",  Inst  a  I  led  on  user  terminals,  are 
sin'1  lo-uscr  modems  which  incorporate  a  set  of 
outbound  call-screening  security  functions  to 
control  access  to  the  host  from  the  user 
end. 

Security  rn  o  0  e  rn  i.  will  not  make  the 
(II  a!“Oti1  connection  until  4  h  e  user  enters  a 
specified  password.  Inside  the*  modem,  those 
passwords  are  matched  In  a  secured  fable  with 
dial -out  telephone  number  sequences  necessary 
to  connect  the  user  to  specified  host 
comp  li  tors,  the  table  also  can  contain  a 
complete  log-on  sequence  for  transmission  to 
the  host  c nee  connection  is  marie#  but  It  I  «» 
advisable  not  to  include  the  log-on  password 
In  1 h i s  soon o  nee . 

"  IHU-£NJ2r_..jB?.Y  1QL.LL  AT  URLS 

In  b  i  g  h  cm  -  s  e  c  u  r  i  t  y  systems,  password 
protection  ot  the  por  t  may  still  seen.  I  n<j.io- 
q  u  a  t e .  A  more  positive  identification  ot  the 
specific  terminal  or  user  may  be  desired.  A 
measure  of  resistance  to  snooping  or  tamper¬ 
ing  with  communications  traffic  may  also  bo 
needed.  the  " two-end"  approach  makes  use  of 
a  su  cur  I  fy  device*  ai  fh»>  user  'or  ml  rial  one! 
w  h  I  c.  h  matches  to  a  device  or  spec  ini  soft  wo  re 
a  f  the  ho  V  \  computer.  1  ti  c*  four  types  of 
devic.es  Ihil  he  I  r<ng  to  the  two- end  solution 
f  am  i  |  y  ,»t  (•  do  sc  r  i  bed  bo  I  ow  . 

U_s.ax_  Au.tii  jniJ-C.at.LtfJi.  i»o-omi 

devices  perform  highly  s  e  c  u  r  o  authentication 
of  individual  system  ij s e r  s .  those  device s 

are  bused  un  the  concept  of  o  unique  "token" 
t  o  h  o  u  s  c»  d  s  om  o  w  h  a  I  I  i  k  e  a  m  e  o  h  a  n  I  c  a  I 
passwor  d .  A  t  v  h!n  is  .3  sm  a  1  I  item,  such  as  o 
p  I  a  s  t  1  c  11  s  m  a  r  t  ~ 1  r  <j  "  ,  given  1c  oac.  h  author¬ 
ized  system  user  tha  f  mu*.  1  tie  used  I  u  gain 

access  I  o  M>  <.  system.  [  ac  h  token  h  a  s  a 
special  fit  'ior  i  f‘  11  or  some  ether  unique  and 

n  o  n  ~  c  o  p  y  a  b  !  e  :  do  n  I  i  f  ior  ombe  d  de  *1  in  it.  I  h  e 

ho  si  o.npijtfM  ran  I  cent  My  the  user  uniquely 
by  m c  o  n  s  c;  f  I  h o  1  uk s  (<  *  .»  d  i  s  t  1  n c  t  ■  v e  1. h  a r  at  - 
ior  i s  t  I c  S . 

Most  v  a  r  i  t  I  o  s  of  iisuf  <1 11  t  h  e  ri  t  i  c  a  f  !  o  n 

tokens  .  t  r  e  li  .5  n  f|  --hi  I  cl  a  n  d  r  eq  u  I  re  no  terminal 

a  t  t  a  c  h  m  e  r>  ■  .  Ini-  typo  of  t  ok  e  n  rn  ay  lake 

var  lous  f-  •  m  s  .  '»upn-  ex  ample*,  new  on  the 

market  include-  a  (  a  I  c  u  I  a  i  or  w  1  I  ti  special 
1  I  r  c  u  i  t  f  y  ,  a  11  sm.j  r  I  "  p  I  a  s  tit.  t  a  r  d  w  h  I  c.  I; 


displays  a  time-based  authenticator  continu¬ 
ously,  and  a  i  Ightsonsl  live  wand  which  Is 
designed  to  read  a  n  c!  interpret  special 
terminal  challenge  displays  sent  by  the 
host  . 

For-  most  tokens,  the  user  must  enter  I  ntc 
the  token  some  challenge  information  sent  by 
the  host.  A  liquid  crystal  display  (LCD)  on 
the  token  then  shows  the  computed  result  of 
the  challenge.  The  user  must  enter  this 
authentication  information  via  the  terminal. 
The  host  reads  the  authentication  Information 
and  romp  arcs  it  1o  I  he  "right1'  answer  it  has 
previously  generated  and  then  decides  whether 
to  approve  access. 

type  of  device  in  the  two- end  solution  family 
is  designed  to  authenticate  a  specific  user 
terminal.  Terminal  authentication  devices 
work  very  much  I  Ike  user  authenticators. 
They  use  matching  pairs  of  devices  inner  tod 
in  the  communications  circuit.  One  device  Is 
placed  between  the  terminal  and  modem,  and 
the  other  Is  attached  to  the  host  computer's 
port,  A  typical  product  includes  a  four-port 
unit  for'  the  host  end  which  is  able  to 
generate  challenges  1  o  the  small  portable 
uni  is  that  connect  to  the  terminals.  Each 
terminal  unit  is  uniquely  encoded  for 
Identification  by  the  host  uni'. 

Hybrid  versions  of  terminal  authentica¬ 
tors  are  also  available,  which  include  the 
capability  1  o  a  u  I  h  e  n  r  I  c  a  t  e  each  user-  at  t  h  e 
some  time.  For'  example,  a  newer  version  of 
the  terminal  unit  just  described  has  a  slot 
whore  each  user  is  to  insert  their  own  token 
in  the  form  or  any  pro-validated  magnetic 
striped  card  (oven  a  Dank  or  charge  card). 
Another  popular  product  takes  a  similar 
approach,  requiring  each  user  to  Insert  their 
own  thick  plastic  cord  with  embedded  Identi¬ 
fication  circuitry  into  the  unique  terminal 
unit.  Both  of  these  products  automatically 
accept  the  t.hal  lengo  from  t  h  u  host,  use  the 

algorithm  cm  d  a  *  a  In  the  user's  token  t  o 

pc»i  c  r  n,  the  1  eg  u  i  rod  calculations,  and  then 
f  r  on  s-ii  It  the  results  to  the  h  o  s  t  for  verifi¬ 
er!  1  I  •)  n  . 

LjLfl.e  .  iln^I.cyji.1  Iqjl  _0.<tyJL<iG:L#  tncrypti  on  I  s  -1  he 
p  r  ntl’  *'■  s  O  f  "  s  c.  r  din!)  i  >  r.  g  "  information  In  a 
p  r  o  -  it  r  1  o  r  rr.  I  n  «mI  way  s  <.-  that  if  if.  11  n  intelli¬ 
gible  t  o*  :i:yor;f*  w  h  o  does  no  I  knew  how  to 

"  u  n  1.  r  cimti  I  <  "  it.  [  n  uyj:  t  i  on  is  r  h  e  highest 
f  o  •  "•  of  h  e  c  u  r  i  I  v  which  con  be  applied  to 
d  :  c !  - y p  communications,  because  it  h  a  s 

s  0  v*  r  a  I  ii  .  1  «'  i  l)ii  in,,  w  ti  i  l.  fi  u'vci  mu  v  I  u  ummu  h  i  - 
cations  sec  ui  I  I y  needs . 

t  :  S  t  ,  t  h  e  primary  rationale  tor  using 
n  «‘r  y  p  t  I  on  is  t  ti  d  t  it  C_Q.tlC.Vd.Li'  the  inf  or  rn  u~ 

I  i  (.mi  p  a  s  s  i  n  q  over  t  h  e  communications  link 

I  r  o  m  ci  i  sc;  I  o  «;  u  r  e  to  snoopers.  S  e  c  o  n  d  , 
l;  n  c  r  y  p  t  ion  in  s  on,  e  modes  to  n  a  s  urc  t  h  o 
Lh.tv_yj.U_y  °f  Inc1  message,  so  that  tamper  i  nq 
or  transmission  errors  can  bo  Identified. 
(Note  that  the  proves s  of  mess a g o  aul hen  t  I- 
C  a  t  Ion,  to  be  discussed  next,  is  hotter  !  or 
a  s  u  r  i  n  q  m  e  s  s  a  go  integrity.)  Third,  the 
h  n  :  cj  u  e  no  s  s  o  f  1 1’  o  encryption  key  wh  i  c.  h  m  u  s  7 
be  shared  b  y  sender  and  rcr.i'i  voi  (’nforc.es  an 
extremely  high  degree  cj  f  user  d.U  Lh.UJl  1  I  .V  Q  _1  i.Qil  - 
If  both  s  e  n  d  0  r  and  r  e  so  i  v  e  r  s  ti  are  a  si  n  c;  [  o 


key,  they  must 
assigned  it  by  a 


have  exchanged 
third  party. 


It  or  been 


Encryption  devices  can  1  d«e  two  forms. 
In  the  more  traditional  form,  the  circuitry 
Is  enclosed  in  a  smal 1  box  that  Is  connected 
In  series  between  the  port  anc  the  modem,  on 
either  end  of  the  communications  circuit.  In 
the  newer  form,  designed  for  personal  compu¬ 
ters,  all  circuitry  is  contained  on  a  single 
circuit  board  tnat  is  plugged  into  one  of  the 
standard  slots  inside  the  computer.  With  the 
t  is  usually  also  possible  to 
uit  board  for  encryption  of 
files,  addition  to  using  it 

tions.  With  either  form,  the 
nations  ports  are  ful ly  protec- 
d  e  r  s  . 


latter  form, 
use  the  c i 
internal  d  i  s 
t  or  c  om muni 
host's  com  ins 
ted  from  in 


W 


Newer  more  sophisticated  encryption 

devices  c . i ■  I  inked  together  so  that  they 

automat  i  ■  ly  identify  each  other  and 
exchange  ■  .  ■  ■  ,  o  n  encryption  keys  in  a  secure 
way  w  1  1  'ii  need  for  human  intervention. 

Till  t  a  l  i  r  e  of  the  key  management  problem 

whikh  li  .•  roubled  encryption  users  from 
a  n  t  i  q  u  i  l  > 


Me  s  s  a  q 

This  a | .  u  c  h  ,  designed  originally  for 
electrui  unds  transfer  (EFT),  can  readily 

be  use  .  -  verify  the  integrity  of  any 
col  lei  ...  n  of  data  being  transmitted  or 
stored  ..id  to  ensure  thal  it  is  not  altered 
w  I  the.  being  detected.  In  the  usual 
commun;  jtlons  application,  a  device  uses  a 
pre-spe  ified  key  to  encrypt  selected  flelcs 
In  a  fur  matted  message,  Alternatively,  the 
device  msy  be  set  to  encrypt  the  complete 
contents  I  any  message  or  data  file  via  the 
key  . 

The  device  uses  the  encrypted  1  ext  to 
form  tne  "message  authentication  code"  (MAC), 
a  cryptographic  checksum  which  it  then 
appends  to  the  clear- text  message  or  data 
file  to  serve  as  a  signature  or  seal.  The 
recipient  must  have  an  Identical  device  which 
checks  the  seal  by  duplicating  Ihe  original 
MAC  generation  process  with  tile  same  key. 
Communications  links  protected  t u I  I  -  1  I  me  by 
message  authentication  devices  would  be 
highly  resistant  to  Intruders. 


ihe  good  news  is  that  the  devices  descr¬ 
ibed  In  the  previous  section  can  sign  i  f  i  -- 
rani  I  y  improve  a  system's  resistance  1c  dial¬ 
up  penetration.  The  bad  new:.  Is  lhat  there 
Is  no  free  lunch,  as  the  saying  goes.  There 
Is  always  a  set  of  negative  aspects  *  o  be 
considered  in  sele cling  new  pro duels.  The 
devices  may  have  weaknesses  which  could  in 
turn  be  exploited  by  intruders,  and  there  aru 
always  sonic  administrative  drawbacks  in  loims 
of  costs  and  in h erunl  usage  problems. 


This  section  discusses  these  negative 
issues  in  order  to  help  the  system  securily 
manager  doc  i  Co  whether  to  use  tne  device.'-  at 
a  I  I  and  evai  date  which  of  thorn  might  be  most 
beneficial-  if  Is  important  to  note  that  the 
weaknesses  or  drawbacks  discussed  here  are 
ilpj  applicable  to  ail  devices  or  models. 


bb 


TECHNICAL  WEAKNESSES 

The  technical  weaknesses  of  dial-up 
security  devices  include  vulnerabilities  in 
the  way  specific  devices  are  designed  or  the 
way  they  are  used.  It  Is  clear  that  adding 
security  devices  to  a  system  will  Increase 
the  security  only  if  Ihe  mechanisms  are  not 
Themselves  flawed  and  if  they  are  used 
properly.  A  practical  analysis  of  dial-up 
security  devices  indicates  that  in  the  worst 
case  they  could  even  degrade  security  by 
inducing  a  greater  degree  of  trust  than 
warranted. 


The  following  discussion  Is  presented  so 
that  the  potential  or  current  user  of  these 
devices  can  better  evaluate  the  device 
characteristics  required  In  a  particular 
application,  be  better  prepared  to  ask 
penetrating  questions  of  device  vendors,  and 
be  more  cautious  about  relying  upon  the 
devices  too  heavily.  This  Information  could 
also  be  used  to1'  background  purposes  In 
framing  equipment  selection  criteria. 

HB-5  1.  a  n _ Weaknesses  .  These  weaknesses  are 

security  (laws  Inherent  In  the  design  of  the 
protection  device.  There  are  known  Instances 
in  which  intruders  have  defeated  certain 
types  of  the  devices  because  of  the  way  they 
operate  or  are  used. 

•  Extra  Passwords  or  Tokens.  Most  of 
the  devices  which  perform  a  direct  user 
authentication  function  have  the  Inherent 
weakness  of  requiring  the  user  to  remember  or 
carry  an  additional  au t h e nt i ca tor  (password 
or  token)  beyond  those  already  needed  for 
system  access.  Many  users  have  Trouble 
remembering  their  ordinary  passwords,  and 
will  commonly  resort  to  writing  them  on  the 
terminal  or  keeping  them  nearby.  Additional 
required  passwords  will  tend  to  amplify  this 
problem  by  making  the  exposure  to  surrepti¬ 
tious  password  discovery  greater  than  It 
already  is.  There  is  a  tendency  to  treat 
tokens  in  a  s  milarly  Insecure  manner  by 
leaving  them  .ear  the  terminal  where  they 
will  be  handy,  instead  of  carrying  them  on 
the  person  and  risking  file  possibility  that 
they  will  be  forgotten  aT  home. 

•  Weak  Password  Mechanisms.  Adding 
port-level  passwords  to  a  system  with  weak 
logical  access  control  procedures  does  not  Lq 
itself  assure  significantly  better  security, 
the  Improvement  in  security  must  come  from 
effective  password  management  procedures, 
wherever  they  are  used.  Hopeful  ly,  these 
procedures  can  be  enforced  or  at  least 
supported  by  file  device  using  them.  The 
design  of  devices  presently  on  the  market 
makes  II  very  easy  to  assign  port-level 
passwords  with  weak  structures  to  users  and 
then  not  change  them  when  needed.  None  of 
the  devices  has  a  way  of  identifying  weak  or 
even  repetitive  passwords.  None  provides  for 
dallng  of  the  passwords  to  determine  their 
age  or  o 1  h  e  r  w  I «  e  provide  for  mandatory 
change.  None  forces  the  security  admini¬ 
strator'  to  p  „  -  g  e  the  vendor-supplied  master 
password  from  tire  system.  Only  'he  call-back 
feature  Is  any  prolection  against  users 
shni ing  Ihe  same  password. 
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•  Security  Event  Logging.  it  was 

pointed  out  earlier  mat  good  security  event 
logging  Is  important  to  assure  effective 
dial-up  security  by  countering  penetration 
attacks.  Many  of  the  add-on  hardware 
security  devices  go  not  provide  this  capabil¬ 
ity  at  all  or  do  so  In  rudimentary  fashion. 
Others  do  not  store  the  information  collected 
in  readily  available  or  easy  to  use  form. 
This  must  be  considered  a  weakness. 

•  Call-back  Interception.  The  call-back 
feature  on  PPDs  which  use  it  can  be  a  mixed 
blessing.  Modern  dial-up  Intruders  typically 
h  -  :ve  access  to  many  of  the  techniques  used  by 
"phone  phreaks"  to  trick  telephone  line 
control  devices.  Some  of  these  tricks  have 
even  been  programmed  into  the  hacker  software 
packages  now  available  via  pirate  bulletin 
boards  and  other  sources.  Call-back  relies 
on  the  ability  of  the  PPG  to  drop  the 
incoming  line  and  Initiate  a  new  call  tc  the 
potential  user.  If  the  Intruder  can  trick 
the  PPD  Into  falsely  sensing  a  line  discon¬ 
nect,  thon  he  can  stay  on  the  I Ine  and  thwart 
the  intent  of  the  PPD's  call-back  attempt. 
This  particular  trick  will  only  work  when  the 
PPD's  Incoming  and  outgoing  lines  are  the 
same  for  a  particular  cal  I  and  the  intruder 
has  already  Identified  a  valid  password. 

Some  PPDs  have  one  set  of  lines  for 
screening  Incoming  calls  and  another  set  of 
lines  used  only  for  making  the  call-back 
connection.  This  design  approach  could  make 
the  intruder's  penetration  even  easier  if  the 
PPD  Is  not  able  to  recognize  an  incoming 
ringing  signal  on  its  outgoing  lines.  The 
intruder  has  only  to  guess  one  of  the 
outgoing  telephone  numbers,  given  a  particu¬ 
lar  incoming  number,  then  call  the  outgoing 
line  and  "camp"  on  it  wltn  a  ringing  signal, 
when  the  PPD  attempts  to  call  out  and  make 
connection  with  a  user,  the  intruder  is  there 
waiting  to  intercept  the  call.  Vendors  who 
make  use  of  call-back  should  be  closely 
questioned  to  determine  whether  their  devices 
can  defend  against  attacks  such  as  those 
d  i  s cussed. 

•  Password  Table  Security.  Devices 
which  use  passwords  have  a  variety  of 
procedures  and  security  features  for  admini¬ 
stering  the  password  tables.  It  this 
security  can  be  penetrated  by  an  intruder, 
then  the  device  has  been  nullified.  Some 
devices  permit  any  terminal  connected  lo 
their  Incoming  port  to  gain  access  tc  the 
tables,  usually  by  furnishing  a  form  of 
supervisory  password.  Other  devices  with 
greater  security  may  require  the  supervisor's 
terminal  to  use  a  special  port.  Some  may 
permit  entry  into  t a b I e - ch ang  i  n g  mode  only 
when  a  standard  brass  key  is  inserted  into  a 
master  switch.  Table-changing  procedures 
should  be  evaluated  carefully  in  terms  of  the 
degree  of  security  improvement  desired. 

•  Penetration  and  B  >ass.  If  an 

intruder  (including  an  insicer)  can  gain 
physical  access  to  1  he  securily  device,  and 
even  worse.  If  he  can  open  It  up,  then  it  may 
be  an  easy  matter  to  nullify  or  bypass  If. 
Only  one  port  protect  ior  device  now  on  the 
market  stresses  physical  Impenetrability  and 
has  a  disconnect  alarm.  Others  have  varying 
degrees  of  physical  hardness,  usual  ly  low. 


All  communications  security  devices  should  be 
protected  by  restricted  physical  access. 

•  Camouflaging  (sign— on  clues).  Dial-up 

security  devices  are  still  not  very  well 
known  to  the  hacker  community,  mainly  because 
not  very  many  of  them  are  being  used  yet. 
Tew  attack  techniques  against  specific  models 
appear  to  have  been  developed  up  to  this 
Time.  Such  will  almost  certainly  not  be  the 
case  In  the  future.  Computer  hobbyists  of 
all  ages  have  repeatedly  demonstrated  that 
professional  software  and  hardware  designers 
have  no  monopoly  on  insight.  Ingenuity  and 
innovation. 

Some  of  the  PPDs  do  not  permit  the 
security  administrator  to  change  the  slgn-on 
screens  or  other  initial  presentation 
features.  Being  able  to  change  them  would 
help  obscure  the  identity  of  the  device 
itself  from  an  Intruder. 

Imp  I eaentatl  on _ Weaknesses  .  Weaknesses  of 

implementation  are  probably  more  Important  In 
a  practical  sense  than  weaknesses  of  design. 
If  a  security  device  Is  not  used  properly.  It 
may  constitute  a  greater  risk  than  If  It  Is 
noT  used  at  all.  Following  are  a  number  of 
typical  implementation  weaknesses  associated 
with  some  dial-up  security  devices. 

•  Password/Authentl cator  Problems.  One- 

end  devices  make  use  of  passwords  to  Identify 
val Id  users.  These  passwords  are  subject  to 
the  same  types  of  administrative  problems  as 
passwords  used  with  the  operating  system  or 
applications.  All  password-oriented  devices 
presently  available  require  the  administrator 
to  assign  and  manage  the  passwords,  which  may 
result  in  the  following  example  problems: 
Passwords  may  be  trivial  in  length  or  con¬ 
struction,  so  they  can  be  easily  guessed; 
passwords  may  not  be  removed  when  no  longer 
needed;  passwords  may  not  be  changed  frequen¬ 
tly  enough;  the  device  vendor  password  may  be 
retained,  with  its  attendant  supervisory 
level  c-f  privileges;  passwords  may  be 
exchanged  between  users  or  shared  with  those 
who  nave  none  assigned.  This  reduces 
individual  accountability  to  near  zero.  A 
similar  sot  of  problems  applies  to  the  use  of 
encryption  without  good  key  management,  as 
wel  I  as  lo  user  authentl cat  ion  tokens. 

•  Incompatibilities  With  User  Terminals. 

Some  PPDs  require  a  Telephone  handset  touch- 
pad  or  the  human  voice  to  enter  the  user 
authentication  Information.  Olher  protection 
approaches,  such  us  external  cncryp+crs  and 
tormlnal  authenticators,  require  the  user  to 
place  a  security  device  In  series  between  the 
terminal  port  and  the  modem.  Unfortunately, 
it  i  rapidly  becoming  commonplace  for  user 
terminals  (Including  portable  and  personal 
computers)  to  be  directly  connected  to  the 
telephone  system  without  voice  handsets  or 
external  modems  or  both.  If  this  Is  the 
case,  then  the  security  devices  will  not  work 
without  re-engineering  1  he  connection  between 
the  -terminal  and  the  telephone  system  I  his 
will  typically  require  some  amoiml  cf  user 
equipment  replacement. 

•  User  Needs  vs.  Lntorcomont  Ability. 

Installing  security  hardware  In  the  dial-up 
circuit  lends  to  Induce  rigidities  In  the 
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ways  that  users  are  able  to  Interface  with 
the  host  system.  In  order  for  some  types  of 
users  to  connect  properly,  some  of  the 
desired  security  features  may  have  to  be 
overridden.  For  example,  PPDs  with  the  cal  I- 
back  feature  enabled  require  the  users  to 
call  from  a  fixed  set  of  terminal  telephone 
numbers.  This  Is  Impractical  If  the  users, 
such  as  travel  I  ng  salespeople,  are  on  the 
road  or  use  more  than  one  telephone  number 
for  their  terminals.  The  call-back  feature 
can  usually  be  selectively  disabled  for  these 
people,  but  then  some  of  the  user  codes  are 
In  effect  less  secure  than  others. 

This  same  situation  could  hold  true  if 
the  user  security  device  were  In  the  form  of 
a  box  which  must  be  Inserted  In  series 
between  the  terminal  and  the  modem,  such  as  a 
terminal  or  message  authenticator  or  an 
encryptor.  This  configuration  might  not 
match  the  types  of  terminals  and  modems  some 
users  have,  and  would  require  special  (often 
less  secure)  procedures  for  them. 


activities.  For  devices  which  use  cal  I -back , 
all  the  telephone  usage  tolls  would  be 
Incurred  by  the  host  rather  than  the  user, 
which  may  make  It  difficult  to  allocate  these 
costs  properly.  On  the  other  hand,  cal  l-back 
may  permit  the  system  administrators  to 
standardize  on  a  single,  low-cost  system  such 
as  WATS,  and  reduce  overal  I  telephone  tol  I 
costs.  Final ly,  some  of  the  two-end  devices 
make  use  of  appl  I  cation  software  operating  on 
the  host  computer  instead  of  stand-alone 
hardware,  thus  Incurring  system  overhead 
costs . 

Management  And  Administration.  In  addition 
to  direct  and  hidden  cost  factors,  there  are 
other  potential  drawbacks  and  problems  In  the 
use  of  dial-up  security  devices  which  may 
arise.  These  can  be  very  significant,  to  the 
point  of  curtailing  the  usefulness  of  the 
devices.  The  following  are  some  of  the  most 
Important  problems  In  usage  that  are  often 
encountered . 


APMUU STRATI VE  DRAWBACKS 

In  addition  to  the  technical  problems  which 
may  exist  in  using  dial-up  security  devices, 
there  are  a  number  of  serious  administrative 
concerns  that  should  be  examined  before  this 
equipment  Is  obtained.  These  concerns  boll 
down  to  money  and  the  problem  of  living  with 
the  devices  once  they  have  been  placed  Into 
operation. 


Cost  Factors.  The  basic  money  Issue  with 
respect  to  dial-up  security  devices  Is  the 
question  whether  they  are  cost-effective  in 
reducing  penetration  risks.  There  are  a 
number  of  cost  factors  involved,  not  all  of 
them  obvious  or  easy  to  calculate.  When 
these  are  added  together  for  a  particular 
appl  I  cat  I  on,  the  cost  for  communications 
protection  via  hardware  may  become  very  high. 
Flere  are  some  of  the  most  significant  cost 
factors  to  consider. 

•  Hardware  Costs.  All  of  these  devices 
tend  to  be  very  costly  to  purchase.  One-end 
protection  Is  the  cheapest;  it  can  be 
attained  for  a  minimum  of  about  $200  and  a 
maximum  of  about  $1,200  per  port,  depending 
on  features  and  level  of  protection. 
However,  the  two-end  devices  are  much  more 
complex  and  costly;  prices  for  complete 
systems.  Including  t erm I n a  I / u se r  devices  and 
host  devices  or  software  can  run  to  as  high 
as  $3,000  per  host/ terminal  link,  depending 
on  level  of  protection  desired.  These 
figures  do  not  Include  instal  latlon  o  r 

periodic  maintenance  and _ repair  of  equipment 

and  software,  both  of  which  may  be  substan¬ 
tial. 


•  Operating  Costs.  There  are  a  number 
of  costs  which  may  be  incurred  from  device 
usaqo  and  operation,  wilh  the  following  being 
some  of  the  most  Important.  User  costs  due 
to  reduced  efficiency  may  be  small  Incremon- 
tally,  but  can  add  up  quickly.  Mo  s  t  of  the 
devices  require  the  user  to  take  additional 
steps  and  submit  to  delays  in  the  process  of 
signing  on  to  the  host.  In  addition,  there 
can  be  significant  labor  costs  from  adminis¬ 
ter  Ln_a  the  security  system.  Including 
password  or  user  token  management  and  related 


•  Identifying  Valid  Users  &  Privileges. 

A  problem  that  is  encountered  when  rigorous 
access  control  systems  of  any  form  are 
installed  Is  to  determine  correct  levels  of 
user  privilege.  Many  organizations  simply  do 
not  have  ai  easy  way  to  correlate  specific 
valid  users  with  the  specific  computer 
systems  and  applications  they  should  be 
permitted  to  access,  given  our  modern  and 
very  complex  communications  environment.  Any 
particular  user  may  enter  a  system  via  dial¬ 
up,  direct  connect,  local  area  network,  wide 
area  network,  and  so  forth.  Certain  Individ¬ 
uals  may  be  authorized  to  access  one  computer 
system  or  application  during  normal  work 
hours  and  use  other  systems  at  al I  hours. 
For  large  systems,  It  may  take  months  to  sort 
out  this  set  of  user  access  conditions,  and 
they  may  be  very  difficult  to  keep  current. 
This  could  substantially  delay  Implementation 
of  rigid  dial-up  access  controls. 

•  User  Convenience  (The  N  u  I  sauce 
Factor).  An  objection  that  often  arises  to 
Improved  security  is  that  it  tends  to  get  i  ri 
the  way  of  val  Id  users.  As  noted  earl  ler, 
most  types  of  dial-up  security  devices 
require  user  overhead  In  the  forms  of 
a  d  d i t  I  o  n  a  I  procedures  to  follow  and  Insertion 
of  delays  in  the  connection  process.  Thore 
may  be  passwords  to  remember  or  special 
dev  Ices  to  carry  and  manipulate.  For  the 
infrequent  user,  the  extra  steps  may  be  very 
confusing  and  frustrating. 

■  i  ii  I  eiiance  of  Authenticators.  In 

operating  dial-up  security  devices  which  use 
personal  user  authenticators  or  passwords, 
there  Is  the  major  problem  of  administering  a 
second  password  management  system,  separate 
from  that  used  by  the  host  computer.  The 
procedures  for  assigning  and  changing  these 
communications  passwords  should  be  rigorous, 
otherwise  the  real  protection  they  can  offer 
will  be  reduce  d .  Usually,  this  means  that 
mor  o  people  will  be  needed  lo  administer  the 
system,  which  may  significantly  increase 
operating  costs. 


UH 


RECOMMENDATIONS 


The  overall  challenge  of  improving  dial¬ 
up  security  is  no  different  from  other  types 
of  security:  determining  the  system's 

security  needs,  evaluating  the  present  state 
of  security,  and  selecting  the  optimal  set  of 
controls  to  raise  that  state  to  the  desired 
level.  This  rules  out  selection  of  security 
hardware  until  It  is  determined  that  these 
devices  are  clearly  justified.  Normally, 
there  are  a  number  of  other  less-costly 
controls  which  should  be  considered  before 
this  justification  can  be  accepted. 

The  following  recommendations  will  aid 
the  security  administrator  to  act  conserva¬ 
tively  and  still  improve  resistance  against 
dial-up  Intruders. 

L» _ S_*  stem  Security _ Adm  1  n  1  st  r  at  I  on  ■  The 

first  and  most  important  step  in  improving 
dial-up  security  is  to  review  and  correct 
present  security  administration  procedures. 
Weaknesses  in  this  area  are  the  single 
greatest  cause  of  intruder  penetrations.  The 
focus  here  should  be  on  ensurinq: 

•  Clear  Individual  accountability,  and 

»  Uniqueness  In  Identification  and 
authent I  cat  1  on . 

In  practice,  the  key  points  to  stress  are 
that  vendor-supplied  USERIDs  should  never  be 
retained  on  the  system,  no  user  should  share 
a  USERID  with  another,  no  USERIDs  should  be 
assigned  or  retained  without  verified  contin¬ 
uing  clear  need,  passwords  should  be  unique 
to  each  user  and  highly  resistant  to  guess¬ 
ing,  and  passwords  shoulc  be  changed  with 
increasing  frequency  as  the  level  of  security 
requirements  r  Iso. 

the  unfortunate  exception  of  current  micro¬ 
computer  versions  (  e  .  g . ,  PC-DOS),  all  ope  r  a- 
l  '  ng  systems  have  some  features  which  can  be 
used  to  improve  their  ability  to  counter 
dial-up  penetration  attempts.  Often, 
however,  system  managers  resist  using  those 
features  because  they  tend  to  reduce  *  h  e 
system's  efficiency  somewhat  or  impede  user 
flexibility.  On  the  other  hand,  installing 
external  security  equipment  has  similar 
effects  and  can  be  more  costly.  Somr  of  the 
operating  system  features  which  are  most 
useful  are: 


s  .  Often, 
using  those 
reduce  *  h  e 
impede  user 
,  installing 
has  similar 
Some  of  the 
ch  are  most 


•  Uso  tho  system's  journalling  capabil¬ 
ity  to  capture  all  secur  ify-  related  ever,  *  s , 
such  as  invalid  attempts  to  log-on  cm  execute 
restricted  programs,  creation  of  new  user 
accounts,  changing  passwords,  and  tne  like. 

•  Uso  the  system's  permission  codes 

(road/write /execute)  to  restrict  access  to 
files  and  programs.  Set  system  defer;  Its  to 
make  all  programs  and  files  private,  which 

will  require  their  owners  to  grant  specific 
permissions  to  other  as  needed. 

•  Use  the  syslem's  ablllly  to  block 
Invalid  log-on  attempts,  in  all  form-,  such  as 
restricting  n  rm;  her  of  a  t  t  .mp  I  I  c  a  n  aw  i  m  i.  in 
of  t  h  r  o*  C  and  t  ll  Oh  4  i  m  i  f.  -  O  IJ  r  r;  o  r  I  ■  f  e  r  ,j 
bh  ur  t  t  i  rn  e  . 


Features.  It  makes  good  sense  to  purchase 
standard  communications  devices  which  have 
innate  security  features,  rather  than  to 
obtain  extra  equipment  solely  to  provide  the 
same  form  of  security  protection.  Various 
manufacturers  now  provide  security-equipped 
devices  such  as:  modems,  protocol  conver¬ 

ters,  multiplexers,  port  contenders  and 
expander s,  and  data  switches.  The  security 
features  may  include  password  tables,  call¬ 
back,  encryption,  user  authorization  by  time 
of  day,  port  restrictions,  and  others. 

4-*. - £ar-±.  Proie^lJ-Qn  Devices  (PPDs)-  If  the 

host  system's  user  identification  and  authen¬ 
tication  procedures  cannot  oe  improved 
easily,  and  the  system  requires  e  moderate 
improvement  in  dial-up  security,  then  PPDs 
may  provide  the  added  protection  necessary. 
It  is  important  to  remember  tha+  PPD  password 
management  must  be  at  least  ac  strong  os  or. 
the  host,  because  the  P P  C  *  S  m  e  i  r  function  is 
to  suppi  cmem  that  of  the  host. 

Additional  r ec om m e n d a t i o n s  if  PPDs  are 
used: 

•  Apply  the  call-back  feature  with 
caution*  It  ipay  not  be  needed  cr  may  induce 
additional  weaknesses.  S  * r o  n c  password 
procedures  ‘or  the  PPD  are  better  'r  the  long 
run, 

•  Use  maximum  camouflage  In  PPD  slgn-on 
screens,  so  the*  intruders  cannot  idenfify 
either  the  p P D  or  the  host. 

•  Use  the  PPD's  logging  features  and 

r  a_v  i  ew  the  legged  data  frequently. 

_ I-fii  m  LiLdJ _ & _ U_s.eE _ AuliLOJil  1  cat  Ion  ■  l f  a 

greater  degree  of  dial-up  security  is  needed 
than  provided  by  PPDs,  then  use  terminal  or 
user  authentication  devices  where  practical. 
For  good  routine  security,  user  authentica¬ 
tion  tokens  ate  adequate.  For  good  user  site 
identification,  terminal  au  +  h  er  *  i  ca  +cr  s  ere 
best.  For  higher  levels  of  security,  use  h  e 
devices  which  provide  bo+h  4ermira!  and  user 
authentication  et  the  some  +  i  n  e  ,  such  as 
terminal  authenticators  which  have  a  slot  for 
a  user  token. 


6.-. _ For  the  h'ghest  levels 

of  dial- up  security,  use  eu^c  no+ic  line 
encryption  devices  which  perform  their  own 
key  management.  A  somewha*  lower  degree  of 
security  can  be  provided  by  encryptors  wh ! Cm 
use  manua1  kev  m a n a gem o n f . 

7_*_ _ The  La  5.1  Word*  To  leaven  a  M  the  above, 

the  security  administrator  should  keep  ! n 

mind  that  computer  systems  exist  4o  be  used, 
and  that  I  h e i r  ready  uso  ; s  now  required  for 
carrying  out  tho  organisation’s,  mission. 
This  implies  that  security  ord  user  producti¬ 
vity  m  u  t _ i  n  a  roj;orai  way.  It 

is  important  to  avoid  "use  surliness"  in 
installing  a  d  d I  t  : o  n  a  I  <  om  m  u  r ' c  e  4  I o n s  security 
p  roc  ed  ur  es  Cr  devices,  by  mokinq  security 

features  as  ‘r an s parent  and  c-cSv  4  o  use  as 
possible.  S  cm  u  r  i  t  y  is  n  o  ?  m > j *  ,  a  1  i  y  exclusive 
with  dial-up  connectivity. 
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INTRODUCTION 

Manual  review  of  computer  system  audit  trails  is  currently  the  only  means  available  to  monitor 
systems  for  security  violations.  Automatic  tools  are  needed  to  assist  computer  system  security 
officers  in  this  task.  This  paper  presents  findings  from  an  investigation  into  automating  the 
analysis  of  existing  audit  trails  for  security  violations  through  the  use  of  pattern  recogni¬ 
tion  techniques.  The  investigation  included  the  analysis  of  actual  audit  data  and  simulated 
intrusion  audit  data.  The  results  were  applied  to  develop  an  automatic  audit  trail  analysis 
tool.  The  investigation  was  performed  for  the  Department  of  the  Navy,  Space  and  Naval  Warfare 
Systems  Command,  under  Contract  Number  N00039-85-C-0136 .  The  results  of  this  investigation 
demonstrate  the  success  of  this  approach.  The  paper  also  discusses  future  directions  for 
research . 


BACKGROUND 

Monitoring  of  computer  system  use  for  security 
violations  will  always  be  necessary.  Even  if 
we  perfect  the  ability  to  design  secure  compu¬ 
tet  systems  which  we  can  trust,  we  can  never 
fully  trust  their  users.  The  problem  of  catch¬ 
ing  legitimate  users  who  violate  system  securi¬ 
ty  will  remain  a  problem  which  can  most  effec¬ 
tively  be  addressed  by  security  monitoring. 

Currently,  system  security  officers  perform 
security  monitoring  of  computer  systems  by 
manually  reviewing  the  system  audit  trail. 

The  only  automated  help  available  to  them 
comes  in  the  form  of  audit  mechanisms  capable 
of  producing  reports  or  data  bases  which  store 
audit  trail  data.  Consequently,  there  is  a 
great  need  tor  more  capable  automatic  tools  to 
assist  in  this  task.  This  need , and  the  lack  of 
work  being  done  to  develop  such  tools,  was 
pointed  out  by  Marv  Schaefer  in  his  closing 
remarks  t.o  the  Eighth  National  Computer  Secu¬ 
rity  Conference.  Although  in  19H0,  the  James 
P.  Anderson  Co.  produced  an  excellent  discus¬ 
sion^  of  this  problem,  not  much  seems  to  have 
bi-en  done  since  then. 

An  automatic:  tool  to  assist  in  the  task  of 
security  monitoring  would  require  data  about 
user  activity  on  the  system.  Audit  trails 
already  provided  by  the  system  are  one  source 
oi  such  data.  They  have  the  advantage  thcd: 
they  are  an  economical  and  practical,  source, 
s’ nee  their  use  would  require  the  automatic 
monitoring  tool  only  to  interpret  the  data  and 
not  collect  it.  on  the  other  hand,  the  disad¬ 
vantage  of  the  use  of  audit  trails  should  be 
recognized.  They  may  not  have  been  originally 
intended  i or  security  purposes  and  may  not 
contain  enough  security  relevant  material.  The 
audit  mechanism  may  not  be  secure  itself:,  so 
that  the  audit  data  it  produces  may  be  of  ques¬ 
tionable  integrity. 

Whatever  its  source  of  monitoring  data,  m 
automatic  tool  can  provide  the  most  assist  nee 
to  a  system  security  officer  by  accurately 
identifying  muni,  luring  data  which  represent 
security  violations.  Perfect  accuracy  is 
likely  to  be  very  difficult  t.o  achieve,  but.  a 
loot  ne«'d  not  tie  perfectly  accurate  to  be 


practical.  Consider  the  two  types  of  errors 
such  a  tool  could  make.  It  can  identify  as 
representing  violations  monitoring  data  which 
do  not  in  fact  represent  violations,  and  it: 
can  fail  to  identify  data  which  do  indeed  repte 
sent  violations.  The  first  type  of  error  .is 
by  far  more  acceptable  than  the  second  typo. 

If  a  tool  could  be  developed  which  would  not 
make  errors  of  the  second  type,  it  could  act 
as  a  reliable  filter  which  takes  in  all  system 
monitoring  data  and  releases  that  data  which 
it  finds  suspicious,  including  all  data  repre¬ 
senting  actual  violations.  The  fewer  errors 
of  the  first  type  the  tool  makes,  that  much 
more  useful  it  would  be. 

In  order  to  make  decisions  about,  which  monitor 
mg  data  represent  violations,  the  tool  will 
have  knowledge  about  the  system  and  its  users. 
The  favored  approach  is  to  have  the  tool  under 
stand  normal  patterns  oE  system  use  for  each 
user.  Any  monitoring  data  not  falling  into 
these  patterns  of  normalcy  would  be  considered 
suspicious  and  possibly  representing  a  viola¬ 
tion.  Another  approach  would  be  for  the  tool 
to  understand  patterns  of  violations,  and  for 
it  to  report  monitoring  data  which  fit  those 
patterns.  While  this  approach  may  be  valuable 
it  should  not  be  relied  upon  solely  since  it 
is  unlikely  that  all  patterns  of  violations 
are  known . 

The  main  goal  of  the  investigation  discussed 
in  this  paper  was  to  determine  the  potential 
of  -a  tool  whose  source  of  monitoring  data  was 
an  audit  trail.  A  reasonable  degree  of  suc¬ 
cess  of  such  a  tool  which  analyzed  even  a 
limited  range  of  audit,  data  would  demonstrate 
that  i he  approach  would  be  more  successful 
when  applied  to  analyze  more  general  monitor¬ 
ing  data.  More  details  can  be  found  in  the 
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investigation's  final  report  . 

The  approach  taken  in  this  investigation  was 
to  organize  the  audit  trail  data  according  to 
which  session  generated  it.  Sessions  were  to 
be  classed  as  normal  or  intrusive  based  on 
patterns  formed  by  their  individual,  audit 
trail  records.  Functions  of  those  fields, 
called  features,  were  defined  to  character i ze 
certain  aspects  of  normal  patterns  lot.  ses¬ 
sions.  Parameters  within  the  features  would 
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differ  f rum  user  to  user  depending  on  individ¬ 
ual  system  usage  patterns.  These  parameters 
were  assigned  values  according  to  audit  data 
describing  only  normal  activity  in  a  process 
called  training.  The  features  were  then  tested 
lor  their  ability  to  discriminate  between  nor¬ 
mal  and  int-usivo  sessions.  Features  flag 
sessions  which  do  not  fit  the  pattern  of  nor 
ma 1 cy  which  they  describe.  Successful  fea¬ 
tures  were  combined  to  create  for  each  user  a 
user  profile  characterizing  that  user's  normal 
system  activity.  An  automatic  audit  analysis 
tool  was  developed  using  those  user-profiles. 

PROJECT  SUMMARY 

From  a  VAX-11/750  running  UNIX  we  collected 
audit  data  that  was  analogous  to  audit  data 
collected  by  general-purpose  systems.  (UNIX 
is  a  registered  trademark  oL  AT&T  Bell  Labora¬ 
tories.)  This  was  accomplished  by  altering 
the  C  shell  command  interpreter  to  collect 
additional  event  attributes  ever  what  the  UNIX 
auditing/accounting  facility  normally  collects. 
No  attempt  was  made  to  construct  a  secure,  tam¬ 
per-proof  auditing  tool.  The  goal  was  simply 
to  gather  a  representative  audit  trail.  The 
data  we  collected  was  compared  to  the  auditing 
information  collected  by  commonly  used  systems 
such  as  SMF  for  IBM/MVS.  Although  only  a  frac¬ 
tion  of  what  would  be  useful  in  characterizing 
usage  patterns  was  collected,  these  fields  are 
representative  of  what  is  likely  to  be  collect¬ 
ed  by  a  commercial  audit  facility.  The  fields 
collected  included  the  uscr-lU,  commands  issued 
by  the  user,  the  current  directory,  the  port  on 
which  the  user  was  logger!  in,  internal  file 
statistics,  and  internal  process  statistics. 
File  statistics  included  owner-11),  size,  and 
times  of  creation,  last  update,  and  last  ac¬ 
cess.  Process  statist ics  included  size  of  input 
anil  output,  running  times,  and  amount  of  memory 
used.  Two  sets  of  audit  data,  each  represent¬ 
ing  one  week  of  auditing,  were  collected  and 
entered  into  un  INGRES  database. 

In  order  t:o  test  which  types  of  intrusions 
could  be;  reasonably  detected  by  auditing,  we 
developed  a  s>M  of  twelve  scenarios  of  abusive 
behavior.  These  scenarios  incLuded  break-ins 
by  huckeis,  legitimate  users  masque  rad ing  as 
other  users,  and  legitimate  users  deliberately 
trying  to  subvert  the  system  in  a  variety  el 
ways.  We  elaborated  cacti  of  these  intrusion 
scenarios  into  i  sequence  of  probable  suspect 
actions.  These  sequences  of  actions  were  per¬ 
formed  oil  the  system,  anil  the  resulting  audit 
data  used  as  a  test  set. 

Based  on  the  Molds  ol  the  audit  data  records, 
we  defined  I  eat ures  and  prepared  lo  test  tor 
t  lie  i  r  effect  iveness.  With  few  exceptions,  each 
ol  the  audit  I  i'-lds  tll.it  we  collected  was  used 
to  did  i  no  a  but  m  ",  In  most  cases  the  fea¬ 
tures  depended  upon  only  one  audit  record 
t  wld,  yet  there  were  features  defined  as  cont¬ 
inual  iuns  ol  more  than  one  field.  Thirty-two 
I  eat  uves  wen'  tested  in  all,  among  wh  i  ill  were 
the  t  line  ol  day  ol  use,  the  command  usage,  and 
direetoiies  and  files  accessed. 

Ft  om  the  (.-at  ures,  we  del  i  ia  d  a  "certainty  mea¬ 
sure."  The  purpose  ol  the  Certainty  measure 
was  to  indicate  I  lie  degree  ol  suspicion  ol  a 
ses  .  i  on  .  II  tin-  I'.i  I  .linl  v  tneasu  i  e  at  I  r  i  bu  t  ed 
In  glvi  v.  1 1  ill's  to  sessions  wh  i  eh  more  I  i  ke  I  y 
i  •  *1 1 1  esen  t  i  n  t  i  us  i  on : . ,  it  would  direct  t  lie  sy  s 


tem  security  officer  to  the  sessions  which 
more  urgently  should  be  reviewed.  The  certain¬ 
ty  measure  would  be  regarded  as  effective  if 
in  testing,  its  values  for  the  intrusion  sce¬ 
narios  were  much  larger  than  its  values  for 
normal  sessions. 

Among  the  goals  of  testing  was  to  determine 
which  features  were  most  effective  at  flagging 
the  intrusion  scenarios.  Certainly,  features 
which  flagged  no  scenarios  would  not  be  consid¬ 
ered  useful  for  intrusion  detection.  A  sec¬ 
ond  goal  of  testing  was  to  determine  which 
features  would  also  flag  few  normal  sessions. 
Since  the  goal  is  to  reduce  the  volume  of 
audit  data  without  eliminating  data  represent¬ 
ing  intrusions,  features  should  flag  as  few 
normal  sessions  as  possible.  A  third  goal  of 
testing  was  to  determine  how  the  features  per¬ 
formed  as  a  group,  rather  than  individually. 
Because  it  would  be  unrealistic  to  expect  that 
one  feature  would  be  sufficient  to  detect  all 
intrusions,  a  user  profile  consisting  of  the 
best  performing  features  would  be  needed  in 
the  audit  analysis  tool  to  detect  as  many  in¬ 
trusions  as  possible  while  also  flagging  as 
few  normal  sessions  as  possible.  A  final  pur¬ 
pose  of  testing  was  to  evaluate  the  certainty 
measure  Cor  individual  features  as  well  as  for 
groups  of  features  as  an  indicator  of  the  like¬ 
lihood  that  a  session  is  art  intrusion. 

The  tests  performed  involved  the  three  sets  of 
data:  week  one  audit  data,  week  two  audit 

data,  and  the  intrusion  scenario  audit  data. 
Week  one  and  week  two  data  represented  normal 
audit  data.  The  tests  were  performed  by  using 
one  of  these  normal  sets  for  training  the  fea¬ 
tures,  and  then  testing  the  features  against 
the  other  normal  set  ond  the  intrusion  scenario 
data  set.  Thus,  when  week  one  was  used  for  the 
training  set,  week  two  and  the  scenarios  were 
the  test  sets.  These  tests  were  actually  per¬ 
formed  first.  When  week  two  was  used  for  the 
training  set,  week  one  and  the  scenarios  were 
the  test  sets. 

In  tb"  tests  using  week  one  for  training,  near¬ 
ly  every  feature  flagged  at  least  one  intru¬ 
sion  scenario.  Therefore,  the  main  measure  for 
the  performance  of  the  features  individually 
was  how  few  normal  sessions  they  flagged. 

Twelve  features  which  flagged  no  more  than  fif¬ 
teen  percent  of  the  week  two  sessions  were 
chosen  lor  the  tests  with  week  two  as  the 
training  set . 

These  tests  confirmed  that  those  features  per¬ 
formed  adequately.  It  is  especially  notewor¬ 
thy  that  in  both  cas-.-s  or  training,  the  user 
profile  formed  from  these  twelve  features 
flagged  all  intrusion  scenarios,  anil  when 
trained  with  week  one,  it  flagged  only  40.9% 
of  the  normal  sessions.  We  considered  this 
quite  good ,  since  it.  was  the  tirst  test  of  this 
unopt imi zed  user  profile.  The  performance  of 
the  certainty  measure  tor  an  intrusion  scenario 
was  twice  that,  of  a  normal  session. 

The  features  which  appeared  to  be  effective 
fall  into  four  categories.  There  are  specific 
releronce  features,  tile  statistic  icat.ures, 
features  based  oil  process  statist  ics,  and  .1 
command  usage  pattern  I nature. 

The  three  spec i  I  1 c  rel evence  features  spotted 
lefeiences  to  commands  or  I i les  which  were 


used  by  one  of  the  intrusion  scenarios  to  sub¬ 
vert  system  security.  They  were  included  in 
the  tests  because  it  was  believed  that  these 
references  occurred  seldom  in  normal  use  of 
the  system.  The  test  of  the  effectiveness  of 
these  three  features  was  whether  they  would 
flag  an  unacceptably  high  number  of  normal 
sessions.  The  results  were  very  good,  with 
very  few  normal  sessions  being  flagged.  This 
seemed  to  be  a  small  price  to  pay  for  captur¬ 
ing  the  intrusive  sessions  which  also  have 
this  feature. 

The  features  defined  by  accessed  file  statis¬ 
tics  which  were  among  the  effective  teatures 
were  defined  by  the  device  on  which  the  file 
resided,  the  size  of  the  file,  and  the  user- 
ID  and  group-ID  of  the  owner  of  the  file.  The 
resident  device  of  the  tile  referred  to  which 
disk  drive  the  file  was  on.  Most  users  showed 
little  variation  in  which  disk  drives  they 
accessed,  as  demonstrated  by  how  few  normal 
sessions  this  feature  flagged.  The  file  size 
feature  identified  the  intrusion  scenario  in 
which  a  user  tries  to  bring  down  the  system  by 
creating  large  tiles  and  occupying  all  avail¬ 
able  disk  space.  It  also  flagged  a  scenario 
in  which  a  hacker  breaks  into  the  system.  As 
expected,  the  features  defined  from  the  user- 
1D  and  group-ID  of  the  owner  of  the  file  ac¬ 
cessed  identified  scenarios  that  included 
browsing . 

The;  effective  features  defined  t rom  process 
statistics  dealt  with  time  ol  use,  timing  of 
the  process,  and  memory  use.  Time  of  use  tea¬ 
tures  effectively  caught  scenarios  of  hackers 
breaking  in  at  night  or  over  the  weekend,  as 
well  as  legitimate  users  logging  in  at  unusual 
times  to  abuse  the  system  in  some  way.  The 
measure  of  timing  of  the  process  which  was 
most  effective  was  the  CPU  time  of  the  user 
programs  (as  opposed  to  the  system  programs) 
associated  with  the  process.  In  this  way,  ex¬ 
cessive  processing  was  flagged.  The  memory 
use  feature  recorded  u  range  lor  the  maximum 
memory  used  by  the  process.  Since  users  have 
little  direct  control  over  memory  use,  it  was 
surprising  that  this  feature  was  so  effective. 
Apparently,  it  is  an  indicat  ion.  of  intensive 
process i ng . 

The  best  performing  command  usage  pattern  fea¬ 
ture  was  one  which  recorded  for  each  command  a 
range  of  tile  minimum  and  maximum  percentage'  of 
tlu:  session  time  spent  in  the  command.  Time 
was  measured  by  CPU  time.  This  was  one  ot  sev¬ 
eral  tested  features  designed  to  measure  how 
much  each  command  is  used.  It  was  interesting 
to  learn  that  CPU  time  is  a  better  measure 
i  hail  tea  1  t  i  me  . 

The  other  features  tested  tailed  because  they 
were  unadaptable,  because  of  the  poor  quality 
of  the  audit,  fields  they  were  based  on,  or  be¬ 
cause  they  were  simply  poor  indicators  of  nor¬ 
ma  J  activity.  for  instance,  the  1 ile  name  and 
the  current  directory  were  the  basis  tor  two 
features  which  performed  bail  1 y .  Since  tiles 
and  directories  are  created  by  users  rather 
often,  numerous  false  (laggings  occurred.  in 
order  to  be  usetul,  leatuies  bin  It  on  these 
t  lelds  should  be  able  to  adapt  l.o  this  dynamic 
situation.  They  need  to  be  able  tu  lea r n  when 
a  i  lew  f  i  I  e  or  directory  is  ni.itml  so  that  i  t 
Can  be  added  to  the  list. 


7 


A  pattern  classification  tool  was  developed 
incorporating  the  user  profiles  based  on  these 
twelve  most  effective  features.  besides  in¬ 
creasing  the  ease  and  efficiency  of  testing 
whether  certain  features  of  the  audit  trail 
database  are  useful  discriminators  of  intru¬ 
sions,  this  tool  can  be  considered  a  prototyp¬ 
ical  audit  analysis  tool.  It  is  essentially  a 
user-interface  designed  to  provide  a  system 
security  officer  with  the  capabilities  needed 
to  use  the  audit  data  base  for  security  pur¬ 
poses.  The  user  can  train  the  user  profiles, 
query  which  sessions  within  the  data  base  are 
flagged  by  the  user  profile  or  by  any  subset 
ol  the  features  in  the  user  profile,  and  view 
sessions  satisfying  a  property  specified  by 
the  user,  such  as  sessions  with  certain  mea¬ 
sure  values  higher  than  a  certain  threshold. 

FUTURE  RESEARCH  DIRECTIONS 

The  results  of  this  investigation  demonstrate 
a  successful  approach  to  the  automated  detec¬ 
tion  of  intrusions  from  audit  trails.  The 
basis  of  this  conclusion  is  the  performance 
of  the  prototypical  audit  trail  analysis  tool 
developed  and  tested  in  this  project.  While 
this  tool  could  bo  adapted  Cox  any  system  sim¬ 
ilar  to  the  one  lor  which  it  was  developed, 
the  approach  could  be  applied  to  virtually  any 
system.  Further  research  is  needed  to  take 
full  advantage  of  the  results  of  this  project 
and  to  develop  a  practical  tool  . 

One  area  of  future  research  must,  be  the  devel¬ 
opment  ol  features  and  certainty  measures 
which  are  more  effective  at  discriminating  be¬ 
tween  normal  and  intrusive  audit  data.  The 
application  of  expert:  system  technology  to 
this  discrimination  should  be  investigated, 
it  is  also  important  to  determine  what  other 
monitoring  data,  not  normally  contained  in 
audit  trails,  would  be  useful.  Selecting  data 
fields  which  are  common  tc,  all  systems  mooting 
a  particular  classification  as  defined  in  the 
"Dob  Trusted  Computer  System  Evaluation  Cri¬ 
teria"  would  make  a  more  generally  applicable 
tool.  Another  area  requiting  further  investi¬ 
gation  should  be  the  determination  ol  the 
amount  of  data  needed  to  train  leu  Lures  must 
etloetivcly.  The  per t on  unco  ol  a  feature 
cannot  be  accurately  judged  if  it  is  inade¬ 
quately  trained.  Finally,  a  large  anil  very 
significant  questions  should  be  how  to  apply 
these  results  to  other  computing  environments, 
such  as  DBMSs  and  networks.  Specialized  en¬ 
vironments  oiler  fertile  ground  lor  progress 
in  this  area.  with  their  narrower  capabili¬ 
ties,  these  systems  would  have  narrower  del  in- 
il  ions  of  normal  use  which  could  be  mol  e  ous- 
i 1 y  character i zed . 
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Abstract 

In  a  resource-sharing  environment,  existing  security  mechanisms 
are  often  inadequate  in  defending  a  system  against  programs  that 
contain  malicious  code  such  as  Trojan  horses  and  computer 
viruses.  Approaches  to  reducing  potential  damage  caused  by  such 
programs  include:  limited  sharing,  dynamic  auditing,  detection  of 
modified  programs,  and  decreased  exposure  to  high-risk  software. 
A  risk  management  mechanism  is  proposed  that  allows 
administrative  classification  of  software  based  on  the  credibility  of 
its  origin,  and  permits  individual  users  to  specify  which  classes  of 
software  they  wish  to  be  exposed  to.  The  goal  is  to  give  users  a 
way  to  avoid  unwitting  use  of  high-risk  software.  This  Risk 
Management  Scheme  is  not  intended  to  be  a  complete  solution  to 
the  problem  of  programs  that  contain  malicious  code;  rather,  it  is 
intended  to  complement  the  authors'  previous  work  in  the  area  of 
computer  virus  containment. 

fourvtfufliaa. 

Wlien  invoking  a  program,  a  user  has  expectations  about  its 
behavior  based  on  documentation,  experience,  and  possibly  the 
source  code  itself;  however,  the  actions  of  that  program  are  only 
indirectly  visible  to  the  user,  if  at  all1.  Thus,  it  is  possible  that  the 
program  contains  some  hidden  function  that  could  have  harmful 
side-effects  such  as  those  caused  by  Trojan  horses  and  computer 
viruses2.  Ideally,  a  computer  system  should  contain  automatic 
mechanisms  to  prevent  introduction  of  such  programs  into  the 
system;  however,  existing  preventative  mechanisms  arc  often 
unsuitable  or  inadequate.  Moreover,  a  prudent  system 
administrator  would  not  place  complete  confidence  in  tbe 
effectiveness  of  any  single  control. 

Other  than  preventing  the  introduction  of  suspicious  programs  into 
a  system,  what  can  be  done  to  avoid  damage?  Protecting  users 
from  malicious  programs  can  be  accomplished  in  several  ways: 

•  by  restricting  users  from  sharing  programs,  thus 
isolating  the  user  from  potentially  malicious 
programs.  Unfortunately,  this  isolationist  approach 
is  not  be  acceptable  if  users  arc  to  benefit  from  each 
others  work. 


•  'ibis  research  was  supported  in  pari  by  the  NSF  Coordinated  Experimental 
Research  program  under  grant  NSE/MCS  8121606  and  by  tbe  HIM  Corporation 
under  contract  0850915. 


•  by  auditing  the  behavior  of  programs  during 
execution,  and  reporting  suspicious  actions  to  the 
user  and/or  system  administrator.  If  one  could  infer 
malicious  activity  with  complete  certainty,  then  the 
system  could  prevent  further  execution,  but  the 
chance  of  halting  execution  erroneously  is  very 
high.  Also,  with  an  auditing  approach  a  user  might 
he  inundated  with  records  of  inocuous  actions. 

•  by  determining  that  a  program  is  potentially 
malicious  prior  to  run-time,  and  preventing  its 
execution.  While  it  is  not  generally  possible  to 
statically  analyze  an  executable  and  infer  with 
confidence  its  proclivity  for  damage,  it  is  possible 
to  detect  modification  of  executables  since  their 
installation3,  a  technique  that  appears  to  be 
promising  for  containing  the  spread  of  computer 
viruses. 

•  by  applying  procedural  controls  such  as  physical 
mechanisms  (c.g.,  guards,  restricted  areas  of 
operation),  configuration  management  policies, 
standard  development  practices,  etc.  Many  of  these 
procedural  controls  should  be  in  existence  in  all 
systems,  and  provide  no  additional  protection 
against  malicious  activity. 

•  by  classifying  executables  according  to  the 
likelihood  that  they  contain  malicious  code,  and 
giving  users  a  way  to  avoid  unwitting  use  of  high- 
risk  software. 

The  last  approach  is  the  subject  of  this  paper.  A  Risk  Management 
Scheme  is  proposed  that  provides  for  administrative  classification 
of  software  based  on  the  likelihood  that  an  executable  is  free  of 
malicious  code  and  also  permits  each  user  to  specify  which  classes 
of  softw'aie  can  be  executed  on  his  or  her  behalf. 

Software  on  a  system  can  come  from  many  places  and  there  are 
differences  in  the  credibility  of  various  individuals  and 
organizations  who  develop  software  for  a  system.  These 
differences  can  be  reflected  by  classifying  the  software  based  on 
the  credibility  of  it’s  origin  as  determined  by  the  system 
administrator.  Thus,  the  likelihood  that  an  executable  is  free  of 
malicious  code  is  determined  by  the  ciedibility  of  its  origin.  Users 
can  then  manage  their  vulnerability  by  choosing  a  risk  level  at 
which  they  aic  willing  to  operate,  thus  controlling  their  exposure 
to  potentially  malicious  programs. 
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Figure  1:  Tho  Process  of  Infection 


The  next  section  provides  background  material  on  lire  types  of 
malicious  programs  and  the  damage  they  can  cause  as  well  as 
some  traditional  protection  models.  A  more  detailed  look  at  the 
problem  is  presented  in  this  section.  The  Risk  Management 
Scheme  is  then  discussed  followed  by  consideration  of  its 
strengths  and  weaknesses.  The  issues  discussed  in  this  paper  are 
part  of  an  on-going  effoit.  Our  long-range  goal  is  to  develop  a 
complementary  set  of  independent  mechanisms  for  protection 
against  computer  viruses  and  other  malicious  programs. 

.UaUmuuad 

Not  all  program  side-elfccts  or  hidden  functionality  arc  had.  This 
discussion,  however,  is  concerned  with  hidden  code  that  is 
deliberately  inserted  by  unscrupulous  individuals,  with  the 
intention  of  causing  malicious  side -effects' '  A  Trojan  noise1' 
hues  unsuspecting  users  into  executing  it  by  pretending  to  he 
nothing  more  than  a  useful  or  interesting  program  ,  while  in  reality 
it  contains  additional  functions  intended  in  "...gain  unauihori/.ed 
acce  s  to  the  system  or  to  Icause  a|  ...main  ous  side  cllect "  .  'I  lie 
diffciencc  between  a  computer  vuus  and  a  Trojan  horse  is  that  a 
vuus  "...can  ‘infect’  other  progiams  by  modifying  them  to  include, 


■»  '|  he  Trojan  horse  works  much  like  (lie  original  wooden  Maine  ihni  ills'  Greeks 
presented  at  Ihc  walls  of  Troy-il  is  an  allraclive  or  innocent -looking  slimline 
(in  i '.is  case,  a  prngiam)  dial  nmi.nns  a  hidden  link,  a  lock  in  the  hum  ol 
hunt'  proglimiming  code  dial  can  give  a  liaekci  siiriepnlioiis  enliy  to  the 
system  Ural  unknowingly  inviies  die  lmj.in  Ihnse  within  ns  iignintivc  walls. 
Tl  e  Tiojan  Irmse  is  veiy  .simple  in  ilietuy,  Inri  also  veiy  el  lee  live  when  it  works. 
I  he  progiam  dial  is  wnuen  oi  intxliln-d  In  he  a  I  loj.m  horse  is  designed  to 
achieve  Iwo  major  goals:  lush  u  me,  lo  look  veiy  imuicenl  aiuyempimg  lo  uni. 
and  second.  11  lias  williin  Used  a  lew  high- seem  My  tasks  lo  uy. 
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u  possibly  evolved,  copy  of  itself."  Trojan  horses  and  computer 
viruses  arc  particulary  insidious  because  they  operate  through 
legitmate  access  paths,  taking  advantage  of  normal  access  riglus 
belonging  to  the  user.  Figure  1  depicts  this  operation  in  the  case  of 
a  computer  virus. 

The  system's  file  space  contains  several  "clean"  executables  lo 
which  the  victim  possesses  modify  access.  The  villain  creates  an 
executable  that  peiforms  a  function  designed  to  entice 
unsuspecting  victims  lo  invoke  it  [imbedded  in  the  executable  is  a 
piece  of  clandestine  code  that  is  a  virus.  When  the  program  is 
executed,  the  hidden  viral  code  is  executed  in  addition  lo  (lie 
program’s  normal  service.  The  victim,  however,  only  secs  the 
normal  service,  and  therefore,  does  not  delect  the  presence  of 
malicious  activity.  The  virus  progiam,  when  executed  by  the 
victim,  typically  carries  the  victim's  access  rights  and,  ihcieloro, 
has  modify  access  to  all  of  the  victim's  executables  as  well  as  any 
other  programs  for  which  the  victim  has  legitimate  modify  access. 
The  virus  copies  itself  to  the  victim’s  uninfected  executables. 
Further,  when  any  oilier  usei  (will)  uppiopiiale  access  rights) 
invokes  one  of  the  infected  programs,  the  virus  spreads  to  that 
user’s  executables  and  so  on.  In  addition  to  its  spreading  property, 
the  vims  may  contain  a  Trojan  horse  intended  lo  cause  damage  of 
some  kind. 

Several  properties  of  typical  computer  systems  lead  to  an 
environment  in  which  malicious  programs  can  wreak  havoc:  lire 
need  for  program  sharing',  the  dilliculty  m  conlining  programs*, 
and  ihc  fact  that  existing  discretionary  access  control  (1)AC) 
mechanisms  arc  fundamentally  Hawed  with  respect  to  limiting 
'Trojan  horses  or  computer  viruses. 

*  A  [migrant  lieu  caii|u.il  ictam  ui  leak  any  nl  Us  pn>|n  icl.iiy  mini  malum  In  a 
l lii i tl  pally  is  Lnnlinod 
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Several  mechanisms  exist  lor  limiting  the  amount  of  sinning  sueh 
as  the  security  and  integrity  policies  '  ,  unit  llow  lists  or  How 
distance  policies'.  However,  to  the  extent  that  these  mechanisms 
permit  any  sharing,  the  damage  caused  by  Irojau  horses  ami 
viames  cannot  he  eliminated  since  their  malicious  activity  is 
conducted  via  legitimate  access  p  iths  due  to  the  fundamental  llaw 
in  DA(\  .Some  work  has  been  done  in  the  area  of  progtum 

jo  1 1  .  *  c  )  ? 

conlinemenl  1  tmd  towards  solving  the  DAC'  problem  “. 
liecttuse  of  the  difficulty  hi  preventing  and  detecting  malicious 
activity,  a  scheme  is  proposed  here  that  can  be  implemented  with 

I  lie  system  administrator*  assigns  software  a  credibility  value 
which  nlentilies  tile  likelihood  that  the  software  contains  malicious 
code.  In  general,  this  value  is  based  on  the  origin  of  the  software. 
Credibility  values  range  from  zero  to  N,  where  software  with  the 
lowest  credibility  has  the  value  of  zero  and  software  with  the 
highest  credibility  on  the  system  has  the  highest  value.  Software 
that  is  fotmully  verified,  so  that  the  possibility  of  it  containing 
malicious  code  is  small,  is  always  assigned  the  highest  value.  The 
number  ol  credibility  values  is  determined  by  the  system 
administrator  and  can  be  one.  Tor  example,  in  an  environment 
where  security  is  o!  primary  concern  sueh  as  a  military  installation, 
a  system  may  he  restricted  to  only  verilied  software.  An 
environment  where  security  is  of  less  concern,  is  unlikely  to  have 
any  loimully  verified  software,  lint,  since  differences  exist  m  the 
credibility  ol  the  various  sources  of  executables,  the  system 
administrator  can  choose  some  number  of  credibility  values  to 
reUcct  the  classes  ol  software  on  the  system.  Figure  2  depicts  a 
possible  eonliguratiim  lor  credibility  values. 


risk  level  lor  all  users  is  the  highest  credibility  value  on  the 
system.  1  he  user  can  reset  this  default  risk  level  by  specifying  the 
desired  default  as  an  argument  to  the  login  command  (e.g„  login 
Joe  -dclaiilt_ri.sk  2).  The  user  need  only  set  this  once  and  it 
remains  m  ellect  until  it  is  explicitly  reset  by  the  user.  Thus, 
assuming  the  default  risk  level  as  the  risk  level  for  the  session 
requires  no  explicit  action  on  the  user's  part  once  it  is  set.  Once 
the  risk  level  for  a  session  ts  established,  any  processes  that  are 
spawned  inherit  the  risk  level  of  the  parent,  restricting  children  to 
running  software  of  the  same  credibility  value  or  higher.  The  only 
way  lor  a  user  to  override  the  risk  level  for  a  particular  session  is 
via  the  RUN -UN  I  KUSTF.I)  command  which  takes  one  executable 
program  as  an  argument.  This  program  can  have  a  credibility 
value  less  than  the  risk  level.  The  duration  of  this  exception  is  die 
execution  of  the  program  supplied  as  an  argument.  'The  objective 
ot  the  1  KUN-IJNTKU.NTFD"  command  is  to  make  execution  of 
high-risk  programs  explicit,  but  not  loo  inconvenient. 
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figure  3.  User's  Risk  Level 
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IJset  Contributed  SAV 
SAV  trom  Bulletin  Board 
SAV  from  System  Staff 
Commercial  Application  SAV 
S/W  from  OS  Vendor 


0  lowest 
1 


0  Highest  Risk 


5  Highest  5  Lowest  Risk 


Tigttie  2.  Cicdihilily  Value  and  Risk  Level 


Ter- User  Risk  Management 

Risk  levels  specify  what  classes  of  software  can  he  executed  for  a 
user.  'I  hey  correspond  invetsely  to  credibility  values,  li  the  user's 
nsk  level  is  set  to  the  highest  credibility  value  on  the  system,  the 
tisk  ol  damage  to  that  u sc- 1  is  llu-  lowest  possible.  On  the  other 
hand,  the  greatest  risk  is  taken  when  the  user  specifies  a  risk  level 
ol  zero 

V  t  ,  use r  lops  in,  a  risk  level  is  established  tor  the  session, 
llus  ■  st.  >el  can  he  detemnned  in  two  ways.  The  lu  st  way  is  lor 
the  i.-'.i'i-  "  speiify  the  desired  risk  level  as  u  i  iguiuent  to  the 
login  so ,ii, mind  (e.g.,  login  Joe  session  risk  ■}.  the  second  way  is 
to  assume  the  delimit  tisk  level  lor  that  user  Initial Iv.  the  default 


As  an  example.  Figure  3  shows  live  possible  credibility  values  for 
soltware,  where  the  existence  of  malicious  code  in  software  with  a 
value  of  5  is  unlikely  and  in  software  with  a  value  of  0  is  most 
likely.  I  he  initial  dclaull  lor  the  user  is  the  ability  to  run  software 
with  a  value  of  5  only,  unless  the  user  explicitly  logs  in  at  a  lower 
risk  level  or  re.sels  the  default  risk  level.  If  the  user  chooses  to 
establish  a  session  with  a  risk  level  of  3,  soltware  with  values  oft), 
1,  and  2  cannot  he  tun  without  using  the  KUNUNTRUSTlil) 
command.  Ol  course,  the  usei  has  increased  the  potential  risk  of 
exposure  to  nialieioir,  activity. 

System  Conliminttiou 

Once  a  credibility  value  has  been  assigned  to  software,  the 
intoi matum  must  he  conveyed  to  the  run-time  environment.  This 
can  he  accomplished  in  several  ways.  'The  first  approach  is  to  store 
the  credibility  value  as  part  ol  the  executable,  comparing  the  value 
with  tbe  user’s  risk  level  prior  to  permitting  execution.  This 
approach  requires  that  the  executable  be  protected  flout 
modilic ation  to  ensure  the  integrity  of  the  credibility  value.  A 
second  approach  is  to  keep  a  list  of  all  executable  software  in  the 
system  and  the  associated  credibility  values.  When  a  user  executes 
a  program,  the  run-time  environment  searches  the  list  for  the 
program's  credibility  value  and  compares  il  with  the  user’s  risk 
level  before  allowing  execution.  .Such  a  list  must  be  protected 
I root  illicit  modification  This  approach  may  not  he  practical 
depending  on  the  lime  it  takes  to  complete  the  search.  \  third 
appio.u  h  is  to  group  soltwaic  ol  the  same  credibility  value  in  the 
same  phu  e  in  secondary  storage,  and  maintain  a  short,  protected 
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list  mapping  credibility  valuer  to  each  file  primp.  Soltxvaro  of  tlie 
same  credibility  value  could  he  stored  in  the  same  directory,  in  the 
same  filesystem*-  ,  or  some  other  mechanism  used  to  partition 
software.  The  list  identity  inp  each  partition  and  the  associated 
credibility  value  is  then  shoit  enough  to  avoid  performance 
problems,  but  must  still  be  protected  from  modification  by  anyone 
except  the  system  administrator,  lupine  4  shows  possible 
credibility  values  for  software  grouped  using  Unix**  directories  as 
(be  partitions. 

As  the  number  of  credibility  values  is  determined  by  the  system 
administration,  so  is  the  granularity  of  the  partitions  For  example, 
one  system  might  paitition  all  vendor  software  in'o  one  partition 
with  the  same  credibility  value  white  another  system  might  have 
separate  partitions  for  1 BN-1 ,  1)1  X’  and  A  i  W I  software,  each  with  a 
different  credibility  value. 
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U  r  Contributed  S/W 

1 
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/usr/net 
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/usr/hin2 

S/W  from  System  Stall 
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/uxrdocal 

Commercial  S/W 

3 

/usr/bin 

Verilicd  S/>V 

4 

/usr /ver 

S/W  from  OS  Vendor 

5  1  lighcst 

/bin 

Figure  4.  Partitioning  Software  ol  Dilfereni  Credibility  Values 

II  an  i  Jividual  progtam  becomes  suspected  of  containing 
malicious  civ":.  uerhaps  based  on  reports  from  other  installations, 
it  can  a:  tin  s  d  an  a  different  directory  of  appropriate  credibility 
value.  I  be  •■.’i,  one  disadvantage  of  associating  a  credibility 
vault:  v.  '  .  ,i  . i c  directories  or  filesystems  is  that  the  full  name  of 
a  pmgru,-  my  be  embedded  in  other  prt>grants  or  scripts:  thus 
movrg  a  r.,-1  •gram  to  a  diltcrem  directory  having  the  desired 
credibility  level  is  essentially  a  name  change  lor  that  piogram,  and 
ni.t1  i  :  us.  existim:  scripts  ,■■  break.  Ibis  obseivation  argues  in 
* ;iv( i-  ; a  ; -signing  eredibi'it)  values  to  indis  iilual  programs,  even 
i  ■  •  '■>  i . j  il.i  so  is  more  u.lnunislutivcly  demanding.  A  Combined 
■.  i  . 1  i.ieli  that  allows  "aw  assignment  ol  uedibilily  levels  to 
ol!  mons  ol  progr;  ms,  F m  piovides  loi  individual  exceptions 
lita*  lv.  lie  iinuiin"  stiateg/ 

SI iTtu'.l li  Vii.I  '•"cak nesses 

"'lie  tn.i;* -r  strength  ol  -.ms  o  u  pi  is  that  it  makes  the  user  aware 
ol  the  potential  usk  in  cxe.  uluti:  c'rl.iin  programs.  Disallowing 
execution  nl  si  Fware  helm  lb-  u  .er’s  risk  level  brings  to  the 
user's  uaention  .soinething.  iFal  ',  p  ..entju'dy  dv  lgcrous.  in  oi'.ev 
words,  executing  such  a  program  does  net  meet  the  system's 

*  In  l  Irux**,  a  lilisYsli-in  oitil.iim  a  tnvi.ueliHal  stmctiiie  of  tliieetmies  anil  files 
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standard  criteria  for  program  execution  at  the  user's  current  risk 
level  Forcing  the  user  to  invoke  the  RUN-UNTI\UST1:D 
command  in  order  to  perform  such  an  action  lets  tie  user  know 
that  tins  boundary  is  about  be  crossed.  The  use  of  the  RUN- 
IJNTRUS TUD  command  does,  however.  n.V'uie  on  normal  user 
operation,  til  choosing  a  default  risk  level,  typical  users  will  try  to 
ensure  that  the  majority  of  commands  they  invoke  svi',1  riot  require 
use  of  the  kUN-lINTRUS  I'liD  command.  This  tendency 
contradicts  the  atmosphere  of  safety  this  mechanism  is  attempting 
to  create.  To  retain  this  atmosphere,  but  still  allow  the  user  as 
much  flexibility  as  possible,  the  system  administrator  can  specify, 
on  a  user  by  user  basis,  the  minimum  risk  level  at  which  a 
particular  user  is  ever  allowed  lo  operate.  A  system  programmer 
or  operator,  for  example,  may  be  restricted  to  a  higher  minimum 
risk  level  dian  a  normal  user.  This  means  that  the  default  risk  level 
can  never  be  set  lower  than  the  minimum  risk  level  for  the  user. 
Further,  when  the  RUN  UNTKUSTUD  command  is  invoked, 
programs  executed  below  the  risk  level  of  the  session  can  never 
have  credibility  value  less  than  the  minimum  tisk  level  lor  tire 
user. 

Determining  how  to  classify  software  ft om  dillerent  origins  is  a 
subjective  decision.  The  system  administrator  must  deteuninc  this 
value  based  on  past  experience  with  the  supplier',  supplier 
leputalum,  and  any  other  available  measures.  For  example,  vendor 
XYZ.  may  have  a  good  reputation  in  the  field,  and  it  is  considered 
unlikely  (bat  any  soltwuie  they  supply  will  contain  malicious  code. 
Software  on  a  network  bulletin  board,  on  the  other  hand,  lias  been 
know  lo  contain  Trojan  horses  and  computer  viruses.  If  the  system 
lias  been  partitioned  as  in  Figure  4,  software  (torn  a  trusted  vetulot 
XY7.  would  be  assigned  a  creel i bitty  value  of  3,  and  placed  in 
/usr/bin.  whereas  programs  from  vendor  not  known  Tor  their 
configuration  management  might  be  assigned  a  credibility  value  of 
2  and  placed  in  /nsr/bin2.  Software  from  the  bulletin  board  would 
be  assigned  a  value  of  1,  and  be  installed  in  /usr/net  or  /ust/flakey. 
A  set  of  guidelines  should  he  created  to  maintain  consistency.  The 
credibility  value  is  a  subjective  indicator,  and  thus,  a  weak  point  in 
the  overall  concept.  I'liis  is  not  a  fatal  weakness,  however,  since 
the  mechanism  is  intended  to  be  a  wanting  system.  The  point  is  to 
make  visible  any  action  which  rallies  potentially  unacceplablc 
risk. 

Matty  systems  allow  the  user  to  specify  where  the  operating 
system  should  look  lo  find  commands  invoked  by  the  user.  For 
example,  the  user  may  wish  the  operating  system  to  first  look  in 
the  user's  directory  and  il  the  desired  command  is  not  found,  to 
then  lool  in  the  experimental  system  lioraries,  and  i!  it’s  slili  not 
loom!  to  look  in  the  normal  system  libraries.  This  process  is  often 
called  name  resolution,  and  the  means  by  which  the  user  specifies 
the  order  of  the  locations  to  search  is  often  called  the  user’s  search 
path.  A  search  path  is  generally  in  cf'eet  for  the  duration  of  a  user 
ses-  uni  and  is  specified  by  the  user  as  part  of  the  session  start  up. 
If  tite  scarct'  path  includes  at  least  one  directory  that  contains 
malicious  programs,  such  as  a  user-contributed  software  library,  or 
the  user’s  "euuent  working  dime  lory",  then  vulnerability  is  high. 
I  or  example,  suppose  a  malicious  progtam  is  given  the  same  name 
as  some  legitimate  program.  Fite  perpetrator  carefully  places  the 
malicious  program  in  a  direc  tory  that  is  searched  before  the  one 
containing  the  legitimate  vetsion.  The  result  is  that  the  user 
executes  the  malicious  piogram  instead  of  the  intended  legitimate 
one.  With  the  proposed  system,  if  a  name  resolves  to  a  program 
with  a  credibility  value  less  than  the  risk  level  established  for  the 
■‘.von.  execution  is  prohibited  unless  the  RUN  UN  I KUS 1  F.I) 
maud  has  been  invoked  and  the  credibility  value  is  not  less 
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than  the  imn  Hum  allowed  lor  the  user.  Thus,  the  set  of 
potentially  damaging  programs  .s  ted  need  to  those  possessing 
credibility  levels  equal  or  greater  to  the  user's  chosen  risk  level, 
pin-  those  programs  executed  explicitly  via  the  RUN- 
UNTRUS  IT'D  command  (lurtherrextneted  by  the  user's  minimum 
allowable  risk  level). 

A  set  of  guidelines  should  also  be  available  to  help  the  user 
determine  the  most  appropriate  risk  level  at  which  to  operate 
depending  on  the  such  t actors  as:  the  sensitivity  of  the  information 
the  user  is  working  on  (e.g.,  proprietary,  company  conlidetntal, 
hum -before  reading,  the  new  rogue  game),  the  t)  pe  of  information 
to  which  the.  user  has  access  (and  to  which  any  programs  run  by 
the  user  will  also  have  access),  the  type  of  environment  the  user  is 
working  in  (e.g.,  development,  operator,  maintenance),  an  soon. 

Second  only  in  importance  to  the  usefulness  ol  the  n is  the 
feasibility  of  any  candidate  implementation.  When  eonsideimg 
irnplememion  ol  the  proposed  Risk  Management  Scheme, 
dependencies  on  the  underlying  operating  system  unit  be 
identified.  There  are  six  critical  aspects  to  the  mechanism: 

•  the  installation  ol  sollwate  into  ducctoiics  v.illi  high 

credibility  values: 

•  the  integrity  of  executables  allci  then  installation: 

•  the  credibility  value  associated  w  ih  a  pat t ienl.tr 
program  or  pailiinm: 

•  the  tiles  or  data  struetuies  storing  nsl.  level 
infoinuiion; 

•  the  illicit  use  ol  the  programs  that  implement  the 
mechanism; 

•  the  integrity  of  the  updating  system  kernel. 

( )f  primal y  i  otieern  is  how  easy  it  is  to  sullen  t  the  mechanism,  for 
example,  how  easy  it  is  tor  a  perpeh.ilor  to  gel  malicious  code 
installed  on  a  system  with  a  high  etedilnlity  value,  or  10  change  a 
user's  i isk  level. 

It  is  essential  that  installation  ot  the  software  he  restarted  to  the 
system  ndmimstialoi.  otheiwise.  d.ingcmus  soltw.in:  can 
masquerade  .it  a  high  eiedihlity  value,  for  example,  in  the 
eonliguratioii  shown  in  l-'ignic  -l,  tl  a  jieipeii.uor  could  install 
software  into  the  /bin  directory  it  would  assume  a  credibility  value 
ol  S,  the  highest  on  the  system.  I  Inis,  failure  lo  resinet  installation 
privileges  retains  this  mn  hunisitt  useless. 

.Since  die  diet liveness  ol  the  system  also  depends  on  preset ving 
the  inlegrily  of  the  executables  themselves,  ibis  scheme  might  be 
combined  with  an  eneiyplior.  meelianism  as  proposed  in  |.’|. 
Allowing  an  executable  to  be  muddied  alter  it  has  been  assigned  a 
credibility  value  and  installed  in  a  partition  invites  insertion  of  a 
Trojan  heist:  ot  computer  virus.  Then,  the  assigned  credibility 
value  will  pn  longer  relied  die  possibility  that  the  soli  ware 
eonMins  malicious  code. 

1’ioiedmg  the  r  lilulny  value  associated  with  a  particular 
program  or  paiMtioii  was  d-  cussed  in  the  System  C 'oiihguiatiotl 
section.  Risk  level  mb  a...  .--i  lalls  into  two  eategoi ies:  the 
default  nsk  level  awl  the  minim  mi  risk  level  which  me  associated 
with  a  inn:  aid  the  pun  ess  n-,k  level  winch  is  associated  with  a 


user's  process.  1  he  ddaiih  risk  level  and  die  minimum  risk  level 
can  he  treated  as  part  ol  the  user’s  authentication  information,  as 
indicated  previously.  These  items  can  then  be  protected  in  the 
same  manner  as  user  passwords.  Protection  of  die  per  process  risk 
level  is  dependent  on  die  underlying  system.  If  the  underlying 
system  is  secure,  ill  access  to  die  process  lisk  level  can  be 
mediated  by  the  busted  Computing  Base  (TCB)I\  If  the 
underlying  system  is  not  secure,  alternative  measures  must  he 
taken  to  protect  the  process  risk  level.  This  issue  is  addressed  in 

llf'l- 

In  addition  lo  being  protected  fiom  illicit  modification,  programs 
that  implement  the  Risk  Management  .Scheme  nuisi  also  be 
protected  tiom  illicit  use.  Routines  that  set  the  minimum  usk  level 
lor  a  user  and  set  the  credibiiilty  value  for  programs  should  be 
restricted  to  the  system  administrator.  In  an  unsecure  system, 
these  operations  can  be  protected  by  performing  them  in  a  system 
stand-alone  mode,  ensuring  that  they  are  not  available  during 
normal  user  operation.  In  a  secure,  environment,  they  would  be 
eonsideied  privileged  operations,  and  part  of  the  'rCB.  Setting  of 
die  default  risk  level  by  the  user,  if  implemented  a.;  part  of  the 
login  process,  can  be  treated  in  a  similar  fashion  to  authenticating 
user  passwouls.  Selling  of  the  piocess  risk  level  is  accomplished 
at  process  creation  time.  If  the  system  is  secure,  authentication 
and  process  creation  would  he  eon  adered  trusted  operations,  and 
would  be  part  of  the  ft 'If.  I’mteetiug  this  meelianism  in  an 
iinlmsied  computing  environment  is  addressed  in  |  16], 

ifUifdUiiUiJfi 

We  have,  proposed  a  mechanism  (hat  allows  users  to  manage  their 
risk  ol  executing  potentially  malicious  programs.  The  underlying 
premise  of  this  mechanism  is  that  useful  distinctions  can  he  made 
about  software  based  on  its  origin.  This  mechanism  is  not  a 
complete  solution  to  the  problem  of  malicious  programs;  it  is 
intended  to  complement  preventative  mechanisms  liuit  currently 
exist  as  well  as  tiiose  described  in  our  previous  vvmk'  ■ 

Our  Inline  plans  are  to  examine  a  pioiolype  implementation  of  the 
Risk  Management  .Scheme  in  order  to  idly  investigate  all  of  the 
implemeiit.il ion  dependencies 
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SECURITY  ON  UNCLASSIFIED  SENSITIVE  COMPUTER  SYSTEMS 
Hal  Felnatein 
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McLean,  VA  22102 

INTRODUCTION  information  system.  The  assumption  that  the  C2  (very 

~  sensitive)  level  ia  sufficient  on  these  systems  has 

This  paper  deals  wi  th  some  of  the  security  not  be#n  cl«arlF  demonstrated. 


issues  facing  unclassified  sensitive  computer  systems 
that  ere  operated  by  the  civil  agencies  of  the 
Federal  Government. 

Computer  security  has  taken  two  directions;  the 
first  la  prompted  by  the  military  and  principally 
designed  to  serve  the  military  need  for  secure 
command  and  control  and  the  handling  of  classified 
information.  This  has  centered  primarily  on  applying 
trusted  software  to  solve  the  multi-level  security 
problem. 

The  second  direction  of  computer  security  has 
been  aimed  at  the  unclassified,  sensitive  systems, 
such  as  are  used  by  the  civilian  agencies  which  deals 
primarily  with  domestic  matters.  Here,  emphasis  has 
been  on  risk  reduction  and  management  within  limited 
resources. 

li.sre  has  been  considerable  desire  to  share 
appropriate  technology  developed  by  the  military  with 
the  civilian  sector.  Problems  of  doctrine  and 
environment  require  redefinition  for  the  civilian 
community  which  is  often  overlooied.  This  paper 
addresses  some  of  these  Issues  and  suggests  Interim 
approaches  where  appropriate  technology  will  not  be 
available  In  the  near  timeframe. 

There  has  been  a  tendency  to  erroneously  place  a 
civilian  agency’s  unclassified  Information  systems 
within  a  military  continuum  of  classifications, 
relegating  it  to  the  lowest  rung  of  protection 
chiefly  because  it  bears  the  formal  unclassified 
designation. 

The  military  classification  hierarchy  is  based 
on  national  security  sensitivity.  Thus,  because 
national  security  considerations  are  not  commonly 
Involved  with  domestic  data,  the  security  of  computer 
systems  handling  such  data  la  not  addressed  from  the 
military  security  viewpoint.  Thus,  without  a  formal 
civilian  sensitivity  ranking  system,  it  is  difficult 
for  system  managers  to  ascertain  what  level  of 
protection  la  required  within  the  trusted  computing 
base. 

A  civilian  agency  information  system  has  certain 
distinctive  characteristics.  They  form  a 
resource-access  boundary  and,  in  many  cases,  may 
represant  a  aeml-autonomous  structure.  Commonly,  an 
information  system  may  be  based  upon  a  commercial 
data  baas  management  system  or  transaction  monitor 
that  haa  control  over  files,  user  terminals,  and 
execution  within  lte  confine*.  Often,  it  is 
tdminlstsred  under  project  auspices  instead  of  a  data 
center  manager. 

Civilian  agency  Information  aystems  may  apan  on* 
or  more  computers  and  contain  data  of  the  highest 
sensitivity.  Yet,  because  of  eeononlc  and 
organisational  uonst taints,  it  may  be  farced  to 
oparata  next  ta  or  than  computing  raaoureat  with 
uncontrollad  or  minimally  controlled  ayitama. 


Perhaps  a  major,  but  often  overlooked  problem, 

Is  the  cultural  differences  between  the  military  and 
civilian  domains.  The  emphasis  and  assumptions 
differ  vastly  between  these  two  groups  and  has 
resulted  in  confusion.  One  symptom  has  been  the 
inappropriate  application  of  the  military 
classification  hierarchy  mentioned  above.  In 
general,  there  Is  a  view  that  the  unclassified 
civilian  agencies  fit  neatly  with  the  framework 
already  developed  for  the  military  and,  by 
implication,  the  guidelines  for  using  the  TCB.  In 
opposition  to  this  is  the  fact  that  the  civilian 
sector  has  evolved  under  a  different  cultural 
framework  and,  hence,  what  is  needed  is  a  new 
conceptualization  of  security  and  not  a  simple 
transfer  of  doctrine  as  some  would  suggest. 

This  paper  describes  the  experience  the  author 
has  had  in  examining  a  lumber  of  civilian  agency 
systems  and  some  of  the  Issues  which  make  direct 
application  of  the  TCB  and  military  guidelines 
somewhat  inappropriate. 

This  paper  Is  divided  into  eight  sections. 
Section  2  reviews  the  environment  of  the  civilian 
agencies  from  a  view  of  their  mission  and 
organizational  framework.  This  is  essentially  an  era 
of  shrinking  resources,  the  Cramin-Rudgman  amendment, 
and  growing  workloads.  It  is  also  an  era  in  which 
the  traditional  centralization  of  the  computer  center 
is  giving  way  to  decentralization.  Section  3 
contains  a  discussion  of  password  usage.  More  than 
any  other  protection  mechanism,  password  type,  method 
of  issue,  and  security  are  an  Indicator  to  the 
individual  style  of  their  associated  Information 
system  and,  often  times,  their  form  and  usage  is 
viewed  as  a  management  prerogative. 

Section  U  contains  an  overview  of  the  method 
used  to  construct  a  security  model.  This  model 
combines  the  information  to  be  protected  with  the 
threat  factors  to  yield  a  mapping  to  the  TCB.  This 
model  is  important  because  it  reviews  a  central 
difference  between  military  and  civilian 
cultures — threat  and  countermeasures. 

Section  3  contains  a  proposed  mapping  between 

aisat  values,  access  clearances,  and  required 

software  trust.  This  model  is  proposed  as  a  basis 
upon  which  civilian  agencies  might  build. 

In  Section  6,  the  C2  class  of  the  TCB  is 
reviswed  and  compared  against  the  threat  model  for 
sufficiency.  This  necessarily  centers  on  the  lower 
levels  of  ths  TCB  below  Class  Bt  however,  argument 
for  a  higher  level  1*  presented,  especially  for  the 
very  eensitiv*  information  on  shared  heats, 

•action  1  briefly  reviews  the  issues  associated 
with  file  encryption  as  a  viable  keel  far  civilian 
agency  sensitive  systems.  Lastly,  the  paper 
concludes  by  reviewing  tha  various  laauoa  prosantod. 


Th*  information  systems  discussed  in  this  paper 
operate  below  the  B-claas  of  DOD  trusted  computer 
base  (XCB)‘.  Thus,  there  sen  be  leas  reliance  on 
the  TCS  sad  acre  on  designing  assurance  into  each 


ENVIRONMENT 

This  section  reviews  some  of  the  factors  which 
are  germane  to  civilian  sector  systems  and  affect  the 
operation  of  unclassified  but  sensitive  information 
systems  In  that  sector,  The  environment  is 
characterized  by  the  need  to  process  a  large  amount 
of  data  of  varying  degree  of  sensitivity  within  the 
same  system.  With  the  move  toward  greater 
productivity  and  shrinking  resources,  data  processing 
is  expected  to  help  streamline  existing  agency 
missions.  Yet,  in  some  cases,  the  rate  at  which  the 
workload  has  increased  outstrips  the  resources 
available  to  civilian  sector  computer  centers. 

There  are  several  factors  that  shape  many  of  the 
decisions  made  in  civilian  sector  systems  and  in  some 
ways  also  shape  the  acceptable  security  approaches. 
The  priority  of  mission,  from  the  standpoint  of  many 
civilian  sector  managers,  is  the  need  to  process,  in 
a  timely  fashion,  very  large  amounts  of  non-sensitive 
information.  Commonly,  this  forms  the  essential 
mission  of  the  agency  and,  hence,  the  chain  of 
command  within  the  agency  views  a  data  processing 
operation  as  successful  if  it  fulfills  this  demand. 
Thus,  funds  and  resources  are  commonly  devoted  to 
servicing  this  goal  first. 

The  civilian  sector  agencies  commonly  depend  on 
commercially-avall able  operating  systems  and  system 
software.  Modifications  and  special  enhancements  are 
typically  added  to  Improve  the  speed  and  reduce 
operational  problems.  System  programming  talent 
within  these  agencies  is  typically  dedicated 
full-time  to  maintaining  the  service  capability  of 
the  computing  systems. 

The  appearance  on  the  market  of  commercial 
access  control  packages  have  greatly  enhanced 
security  In  these  centers  by  providing  a  package  of 
security  tools  not  requiring  development  but  only 
Installation. 

The  second  majo.  factor  which  conditions 
unclassified  sensitive  systems  is  that  there  Is  no 
consistent,  community-wide  classification  system  in 
use  across  all  civilian  sector  agencies.  The  military 
or  national  security  classification  hierarchy  deals 
specifically  with  information  affecting  the  national 
security.  Some  Information  handled  by  the  civilian 
agencies  does  affect  the  national  security  and  this 
information,  when  originating  within  classified 
programs,  bears  the  proper  nationaL  security  or 
military  designations. 

There  it  no  parallel  claaalf ication  scheme  and 
handling  protocol  available  to  civilian  sector 
manager*.  Some  department*  have  lnatUuted  special 
handling  categories  which  apply  only  to  their 
department.  Commonly,  they  designate  a  two-level 
approach,  designating  a  restricted  class  of 
information  which  must  be  specially  handled.  In  some 
caaes,  this  special  handling  level  resambiss  a 
mixture  of  "official  use  only"  and  "confidential." 
Often  times,  this  single  special  leva!  ia  meanlnglaas 
when  applied  to  all  the  agency'*  sensitive  data 
btcaua*  it  dote  not  provide  the  handler  with  a  dear 
indication  of  the  information's  true  sensitivity. 
Renee,  other  agencies  which  may  ect  es  temporary 
ousted  Ians  of  the  information  for  purposes  of 
•Pilysie  or  iterate  My  not  routinely  reeognlie  or 
enforce  the  information's  true  protection 
requirement*, 

Moot  apodal  handling  caveat*  art  department  or 
agency  specific.  Whan  information  ia  transferred 
across  department  or  atoncy  boundaries,  there  is 
often  an  uneven  end  ad  hoe  approach  ts  interaction 


protection.  This  is,  in  part,  tho  result  of  the 
assumptions  producers  make  about  how  the  information 
ia  being  protected  and  hew  aerlou*  the  recipient 
consumer  or  custodian  ia  in  providing  the 
protection.  It  seams  that  this  often  unverbalised 
assumption  presents  one  of  the  real  danger*  in  the 
unclassified  sensitive  sector  because  the  producer  of 
the  information  may  be  only  vaguely  aware  of  the 
exposures  present  in  a  custodian's  or  consumer's 
computer  system. 

There  have  been  limited  efforts  to  create  a  sat 
of  sensitivity  classes  which  would  be  recognized 
government-wide.  The  National  Telecommunication  and 
Information  System  Security  Committee  (NTISSC)  staff 
it  attempting  to  define  a  meaning  for  the  term 
"sensitive";  however,  this  effort  seems  confined  to 
designating  unclassified  data  which  is  important  to 
the  national  security  as  opposed  to  Information  of 
domestic  Interest. 

Defining  government-wide  sensitivity  levels  for 
domestic  data  would  go  a  long  way  toward  eliminating 
the  confusion  and  variability  In  data  protection 
commonly  seen  today.  It  would  vastly  improve  the  way 
in  which  data  protection  planning  is  currently 
approached  by  providing  a  set  of  well-defined 
planning  targets  and  a  consistent  measurement  of 
provided  protection. 

A  third  factor  is  the  need  to  make  use  of 
systems  currently  in  place  and,  In  addition,  the  need 
to  share  resources.  A  sensitive  information  system 
often  executes,  side-by-side,  with  non-sensitive  and 
perhaps  even  uncontrolled  systems.  This  Is  a  result 
of  the  need  for  sharing  of  mainframes  since  there  is 
an  economy  of  scale  ' rade-off  typically  used  in 
planning  many  larc-  omputer  systems. 

It  is  not  uncc.iron  to  see  jobs  of  various 
security  levels,  both  online  systems  and  batch  jobs, 
executing  on  the  same  mainframe.  This  is  on  example 
of  multl-sensitlvlty  (similar  to  multi-level  but  with 
unclassified  information)  operations  run  under 
non-trusted  software.  Multi-sensitivity  operations 
on  untruated  software  carry  with  it  a  risk  which  is 
difficult  to  estimate.  In  an  extreme  case  which  ia, 
however,  not  hypothetical,  very  sensitive  information 
which  is  available  only  to  a  restricted  set  of 
specifically  "cleared"  individuals  ru  .s  side-by-slde 
with  non-sensitive  information  systems  which  have 
minimally  controlled  access. 

Thus,  how  much  confidence  should  be  placed  in 

the  commercial  operating  system,  disk  access, 
terminal  handier,  transaction  monitor,  and  data  base 
to  ensure  that  unwanted  intrusions  are  prevented? 
There  are  two  additional  dimension*  to  this 
probl«m--s*parating  different  groups  of  cLaared 
individuals  within  the  information  system  and  the 
old-new  problem. 

Gaining  administrative  clearance  to  access  an 
information  system  usually  entails  two  separate  and 
different  acceaaes.  The  first  allow*  tha  user  to 
sign-on  to  th*  online  system  itself,  while  the  second 
permit*  him  to  acces*  certain  aenaitlve  fllea  within 
tha  information  ayatem.  This  latter  acctta  might  ba 
termed  "file  acoeaa"  since  this  is  thd  mechanism 
where  access  control  la  typically  enforced. 

We  have  already  asked  the  question  concerning 
the  ability  of  tha  Interaction  system  to  prevent 
outside  users  from  aoeeaalng  let  namely,  aooesa  by 
ueera  who  have  not  been  granted  administrative  accaas 
to  the  information  system  at  all. 


X 


The  second  question  we  pose  Is  can  an 
information  system  prevent  users  who  have  access 
rights  to  it  from  accessing  flies  to  which  they  do 
not  have  a  right?  This  question  is  central  to  secure 
software  efforts  and  can  probably  be  answered  in  the 
affirmative.  Demonstration  on  a  number  of  trusted 
systems i  such  as  the  Honeywell  SCOMP  and  the  various 
securs  UNIX  efforts,  Is  possible.  However,  how 
should  it  be  answered  for  a  traditional  commercial 
transaction  processing  package  and  operating  system? 

The  second  dimension  of  the  problem  is  the 
old/new  issue  which  arises  from  attempting  to  modify 
and  extend  old  information  systems.  Often  these 
systems  were  designed  with  elementary  or  Inadequate 
security  considerations.  These  systems  have  been 
systematically  extended  over  the  years  resulting  in  a 
culmination  of  "loosely  coupled"  software 
subsystems.  Security  control  is  often  ad  hoc,  or 
easily  bypassed;  few,  if  any,  sophisticated 
penetration  analyses  have  been  performed  and  only 
rudimentary  audit  trails  exist  when  they  exist.  In 
some  cases,  passwords  are  stored  in  plain  text, 
something  ancuuntered  more  commonly  titan  would  be 
expected;  In  other  cases,  "homemade"  password  and 
data  encryption  algorithms  are  used. 

Comparatively,  soma  newer  sensitive  information 
systems  >  nt  uni  I  v  under  tl«\ e  lopmen  t  have 
we  1 1  -des  1  gur.il  enmity  featmes  built  Into  the  lower 
level  of  the  inf  onn.il  ion  system.  This  lower  level  is 
a  for'.,  of  executive  process  for  the  information 
system  preforming  and,  hence,  mediating  ar-'uxs  to 
sensitive  filas,  devices,  and  transactions.  Each  new 
application  within  the  information  system  will  find 
that  security  mechanisms,  such  a»  access  control, 
auditing,  authentication,  and  transaction  control, 
are  built  in  as  primitive,  low-level  operations.  The 
lower  level  security  "base"  is  maintained  by  an 
experienced  and  trusted  system  programmer ,  while  the 
complicated  and  extensive  applications  code  might  he 
contracted  out  to  n  software  development  contractor. 

Agencies  responsible  for  design  of  the  newer 
information  systems  commonly  Include  security  as  one 
of  the  primary  attributes  needed  by  their  system  from 
the  beginning  of  the  planning  process.  in  addition, 
they  understand  what  modern  software  security 
approaches  are  available  and  see  to  It  that  they  were 
Included  in  the  system  design.  Often,  a  central 
access  matrix  or  access  list  is  used  to  allow  easy 
maintenance  of  user  privileges.  These  information 
systems  tend  to  have  some  of  the  best  security 
characteristics  encountered  For  that  environment. 

Comparatively,  some  information  system  design 

groups  take  the  approach  that  security  would  be  added 
on  after  the  Information  system  was  Implemented, 

These  groups  tended  to  view  security  as  primarily  the 
responsibility  of  the  data  bast  or  transaction 
monitoring  system  chosen  for  the  implementation.  It 
appears  that  security  in  this  approach  mutt 
necessarily  reflect  the  ad  hoc,  uneven,  and 
frequently  fragmented  security  mechanisms  available 
from  the  commercial  products  upon  which  the 
Information  system  ii  built.  This  ha*  usually  been 
born  out  by  experience. 

In  sum,  civilian  agenda*  are  faced  with  the 
problem  of  scarce  resources  against  growing  workloads 
and  old  system*.  These  systems  contain  weak  security 
features!  however,  they  continue  ta  be  useful  and 
WiU  pass  problems  in  the  future.  Good  sacurlty 
techniques  era  known  By  selective  groups  within  each 
civilian  agency.  Making  these  techniques  available 
will  greatly  enhance  the  future  security  of  agency 


Information  systems.  A  stronger  policy  will  be 
needed  to  treat  the  ln-place  weaker  systems  where 
retrenching  and  security  enhancements  may  be  required. 

VARIATION  IN  PASSWORD  USACE 

Authentication  of  the  user  is  of  primary 
importance  in  information  systems  and  is  comnonly 
done  with  passwords  or  challenge-response  devices, 
such  as  a  DES  calculator.  As  with  any  authentication 
token,  the  doctrine  associated  with  their  use  is  a 
critical  aspect  of  their  security.  A  reasonable 
protocol  for  password  generation,  distribution,  and 
use  is  presented  in  the  NCSC  "Password  Management 
Guide"^,  and  under  the  C2  doctrine,  each  user 
should  possess  an  individual  password  to  allow 
accountability  to  the  single  user  level  of 
granularity. 

In  comparison  to  the  C2  doctrine,  we  have  found 
that  within  a  single  shared  civilian  computer  system, 
there  is  a  wide  range  of  password  practices.  Each 
information  ayatem  may  command  its  own  doctrine  of 
use;  thus,  It  is  not  uncommon  to  find  a  very 
sensitive  information  system,  perhaps  written  using 
IBM's  Customer  Information  Control  System  ICICS)  to 
require  rigid  conformance  to  the  C2  doctrine,  while 
along  side  it  and  in  the  same  mainframe  is  a 
non-sera i tive  application  whose  passwords  conform  to 
Cl  (group  passwords)  or  less  (no  pussword). 

Examination  of  several  vine lass  it  led  systems 
reveals  a  number  of  operational  doctrines  different 
from  the  C2  doctrine.  These  are  listed  in  Table  l 
and  ate  ranked  from  "least"  sensitive  to  very 
sensitive.  Each  of  the  systems  In  themselves  do  not 
violate  given  norms  of  security.  The  major  problem 
is  when  they  are  mixed  on  a  contra  1  mainframe  using 
commercial  tton-secure  operating  systems. 

The  first  examined  In  Table  1  is  that  of  a 
public  information  and  retrieval  system  which  uses  no 
passwords  and  is  available  to  the  general  public. 

This  service  la  somewhat  new  and  is  aimed  at 
providing  the  public  with  the  latest  information 
regarding  announcements,  rulings,  and  orders. 
Originally,  terminals  to  these  systems  are  placed  in 
the  lobby  of  the  agency's  office  and  are  open  to 
all.  However,  dlal-in  mode  of  access  is  now 
beginning  to  make  its  appearance.  Some  experiments 
have  been  done  with  publ ic-to-agcncy  electronic  mail 
in  which  the  mail  package  tuna  on  the  agency's  host. 
The  public  information  systems  are  commonly 
implemented  using  one  of  the  commercial  transaction 
monitors  and,  hence,  the  "isolation"  one  can  expect 
is  an  open  question. 

Public  information  terminals,  electronic  mail, 
and  public  information  date  bases  are  attractive  in 
term*  of  enhanced  efficiencies  and  a  tool  useful  to 
the  public.  This  service  will  probably  continue  to 
gain  popularity  In  the  future  and,  hence,  represent  a 
potential  problem  area  for  the  security  of  shared 
agency  hosts, 

The  second  example  in  Table  1  is  the  "strong 
room"  mod*  of  password  usage.  In  this  example,  only 
cleared  individuals  have  unescorted  access  to  this 
strong  room,  The  premise  Is  thet  only  persons  with 
the  proper  need- to -know  can  enter  thle  strong  room; 
therefore,  there  Is  no  need  for  further 
euthentlsetion.  Thle  corresponds  roughly  with  the  Cl 
doctrine  of  group  paeswerde  in  *  cooperative 
environment.  Vet,  prudent  hendllng  of  thle 
unclassified,  yet  sensitive,  information  would  seam 
to  require  accountability  at  the  individual  level  of 
granularity.  The  style  of  operation  in  thee*  strong 


TABLE 

l 

PASSWORD 

USAGE 

Logon 

Passwords 

Information 

System 

File 

Public  Information  Terminal 
Resident  in  Agency's  Lobby 

No 

No 

Public  Information  and  Agency  No 
Announcements  Available  via 

Public  Dlal-ln  Access 

No 

Funds  Disbursement  System 

Yes 

Yes 

Regulatory  Investigative 

Dati  Base 

Yes 

Yes 

Confidential  Informant 
Identicies  (terminal  located 
in  controlled  area  (strong 
room  model)] 

Group 

Croup 

Counter  Style  Service 
(off  ice  model ) 

uroup 

Physical  Lock 

rooms  are  dependent  on  the  responsible  managers  and 
varies  from  group  to  group.  Tightly  knit  groups  tend 
to  operate  as  a  "skunk  works"  typically  relaxing  some 
rules  in  favor  of  the  mission.  Large  groups  require 
more  accurate  tracking  of  Information  and. 
unfortunately,  may  not  employ  adequate  methods.  it 
is  probably  this  latter  group  that  will  gain  from  the 
C2  doctrine. 

The  third  example  in  Table  1  is  the  "office" 
model  of  password  usage.  In  this  model,  the  public 
is  being  serviced  by  agency  personnel  from  "windows" 
which  contain  a  terminal  hooked  into  the  agency's 
information  system.  The  agency  person  may,  from 
cime-to-time,  leave  the  terminal.  The  terminal  could 
then  be  manipulated  by  an  unauthorized  person. 

To  prevent  this  type  of  compromise,  some 
information  system  designers  have  introduced  the  use 
of  physical  locks  on  the  terminal  which  lock  the 
keyboard  and  blank  the  scieeu.  Some  simply  lock  the 
terminal  keyboard  but  do  not  blank  the  screen.  The 
agency  uaer  removes  the  key  and  takes  It  with  him  to 
prevent  compromise  or  alteration. 

This  third  example  Is  Important  because  It 
brings  out  an  important,  but  overlooked, 
authentication  pr oblem-- transact  Ion -or  tented 
authentication.  Common  use  of  account  Identity  and 
passwords  Is  designed  to  be  session-oriented  commonly 
authenticating  an  entire  session  from  logon  time  to 
logoff  or  aesslon  termination  time.  Because  a 
■eaaion  typically  exlata  over  •  significant  period  of 
time i  it  it  acceptable  for  the  user  to  perform  the 
manual  operation  of  antaring  the  passwords  and 
account  name  since  this  is  dons  once  per  session. 

The  overhead  tlma  associated  with  performing  a  logon 
ia  acceptable  because  It  Is  done  once  for  the  entire 
•esalon. 

Comparatively,  a  transaction  can  be  viewed  as  s 
short  unit  of  work  which  is  performed  many  times  ov«r 
the  period  of  a  sasslon.  The  oparational  premise  of 
aeaalee  lagan  la  that  the  uaer  will  kaap  control  of 
the  taralMl  for  the  duration  of  the  session,  yet, 
there  c»f  eireuMtaneea  where  this  it  net  true, 
especially  in  the  case  of  the  "strong"  room  model  and 
the  "off tee"  modal. 


Whs .  is  needed  i*  the  ability  to  authenticate  a 
uaer  bated  not  on  a  session,  but  on  a  transaction 
basis.  Conventional  account  name/password  pairs  are 
inadequate  for  this  role  because  the  logon  Itself  i* 
an  example  of  a  transaction. 

Soma  approaches  have  been  suggested  for  the 
transaction  authentication  problem.  Chiefly,  they 
center  on  eliminating  the  delay  associated  with 
manual  account  name  and  password  entry  by  using  a 
badge  reader  to  gein  this  information.  The 
information  read  from  the  badge  could  be  appended  to 
an  inviaible  field  prefacing  the  uaer  text  record. 

An  unsolved  aspect  of  this  issue  ia  the  additional 
processing  time  added  for  each  account  name/password 
verification.  This  might  best  be  dealt  with  by  a 
fast  verification  technique  different  from  that 
developed  for  session  authenticetion. 

The  last  example  of  password  usage  shown  in 
Table  1  is  the  shorter  than  required  password.  Thi* 
is  essentially  a  human  factors  problem,  and  it  is 
common  to  find  installations  where  eight-character 
random  password  combinations  are  systematically 
changed  and  result  in  users  writing  them  down.  Some 
relief  can  be  expected  from  passwords  composed  of 
pronounceable  syllables  or  pass-phrases;  however,  the 
doctrine  of  random  string  passwords  systematically 
changed  is  a  problem. 

To  overcome  this,  some  information  systems  have 
adopted  four-character  passwords,  while  others  simuly 
do  not  change  them  allowing  users  to  memorize  them 
through  long-term  use, 

it  is  clear  that  while  passwords  are  currently  a 
useful  authentication  technique,  the  management  and 
human  factors  overhead  associated  with  them  is 
great.  New  methods  commonly  employing  DES 
calculators,  badge  readers,  and  smart  cards  are 
beginning  to  make  their  way  Into  use  within  the 
civilian  sector  but  are  still  relatively  expensive. 
Primarily,  they  are  first  considered  for  very 
sensitive  security  applications  because  they  commonly 
afford  two-step  (what  the  user  knows  and  what  the 
user  has)  authentication  as  opposed  to  one  (a 
password). 

Each  of  the  examples  discussed  (the  public 
Access  system,  electronic  mail,  the  strong-room,  and 
office  model)  illustrates  an  Important  principle. 

This  principle  rests  on  the  view  that  user 
authentication  should  be  tailored  to  the  environment 
in  which  it  is  used.  Shorter  passwordo  may  suffice 
if  a  proper  password  checking  mechanism  was  also  In 
place.  This  mechanism  would  prevent  trials  by  an 
unauthorised  uaar  and  would  quickly  lock-out  too  many 
attempts.  Including  s  mandatory  delay  time  also 
lowers  the  chencee  of  e  successful  brute  force  ettack. 

In  sum,  it  may  not  be  necessary  for  every 
cpplicatlon  of  password*  to  strictly  conform  to  the 
C2  doctrine,  The  mode  of  operation  and  degree  of 
induced  risk  should  be  analysed  on  a  case-by-case 
basis • 

SENSITIVITY  AND  PROTECT  ION 

Allocating  sufficient  protective  resources  is  an 
tiaential  Management  decision  in  the  civilian  aector 
which  must  be  carefully  meeeured.  There  ere  two  . 
philosophical  view*  commonly  employed  for  allocation; 
the  civilian  agency  view  end  the  si lit ary  or  national 
security  view.  While  utilising  similar  methods  of 
risk  analysis  to  allocate  resources*  thesa  views 
differ  primarily  in  thei*  understanding  of  the 
world,  tn  turn,  this  is  seen  as  a  natural 
consequence  of  the  mission  end  environment  in  which 
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each  operate a.  Thit  aection  contain*  a  brief 
examination  of  son e  of  the  iaaue*  effecting  the 
attlmatlon  of  threats  and  assignment  of  protections 
for  each. 

Devising  a  protection  scheme  is  a  two-step 
approach.  The  first  step  in  devising  a  protection 
schene  is  to  have  a  way  to  optimally  utilise  limited 
countermeasure  resources.  Countermeasure  in  this 
esse  consists  of  measures  used  to  enforce  system 
security  above  what  Is  available  with  a  standard 
commercial  software  package  or  which  is  available 
without  cost  from  the  information  systems  data  bass 
or  transaction  monitor.  This  includes  Investment  in 
an  access  control  package)  enhancements  to  the 
operating  system)  or  other  security  modifications. 

The  method  used  for  protection  estimation  ia 
similar  to  the  common  average  loss  expectancy  (ALE) 
approach  commonly  used  in  risk  analysla/risk 
reduction.  The  ALE  method  is  quits  popular  in  the 
civilian  sector  for  allocating  risk  reduction  funds. 

It  ia  recognised  by  most  federal  agencies  as  a  valid 
and  adsquate  approach  to  identifying  and  ordering  the 
major  risks  and  estimating  the  sufficiency  of  a  risk 
reduction  strategy. 

The  ALE  is  a  four-step  approach  in  which  the 
individual  asset  value  and  loss  event  frequency  are 
compared  against  strategies  of  backup  allocation.  In 
the  first  step,  each  asset  is  identified  and  a  dollar 
value  Indicating  its  replacement  cost  is  assigned. 
Second,  all  threats  are  identified  and  a  probability 
of  s  compromise  or  security-significant  event  <s 
computed.  Third,  the  probability  of  an  event  is 
combined  with  the  loss  value  of  that  asset  acted  upon 
to  yield  a  total  expected  Loss  value.  If  this  value 
is  computed  for  critical  assets,  for  example  in  a 
computer  center,  then  a  manager  can  decide  wliers  best 
to  optimally  place  scarce  contingency  resources. 

A  contingency  resource  might  replace  an  asset 
lost  in  an  attack  or  disaster  or  it  might  provide  a 
reduced  capability.  The  cost  of  replacement  or  of  an 
Interim  measure  to  offset  loss  of  a  critical  awset  is 
subtracted  from  the  expected  loss.  Thus,  the  fourth 
step  Is  to  test  different  allocation  strategies  of 
replacement  resources  to  minimise  the  expected  value 
of  loss. 

The  ALE  approach  can  be  applied  to  Information 
syetems  by  first  calibrating  the  frequency  of  s 
security  event  against  that  data.  An  svant  of  this 
type  could  be  a  compromise,  manipulation,  theft 
(removal),  or  denial  of  service  attack.  In  turn,  the 
probability  of  attack  is  multiplied  by  the  damage 
done  to  the  asset  estimated  in  dollars.  This  ylslds 
an  expected  loss  value  which  can  be  used  to  allocate 
funds  to  a  protection  strategy. 

After  e  protection  strategy  has  bean  picked  and 
the  ALE  recomputed,  there  la  commonly  •  residual 
amount  of  risk  which  oannot  ba  serviced  under  e  given 
budget.  This  risk  commonly  center*  on  infrequent  or 
unusual  events  which  ere  considered  improbable { 
however,  frequently  it  Is  much  more  likely  that  risks 
can  only  be  partially  addressed  under  a  currant 
budget.  These  "unfunded"  risks  era  present  in  thj 
systems  operation  and  are  commonly  judged  by 
management  to  bo  eeeoptable  levels  of  risk  for  a 
given  operation.  Those  residual  riaka  are  treated 
under  the  heading  of  riak  management. 

While  the  AU  method  has  found  wlds  acceptance 
aa  a  risk  objections  reduction  allocation  method, 
there  are  numerous  objections  to  it  both  practical 
and  philosophical,  Briefly,  the  practical  objections 
center  on  eht  process  of  estimating  the  dollar  value 


of  important  information  in  a  data  base  end  the 
frequency  of  certain  type*  of  attacks  on  chat 
inf onset Ion.  An  example  is  an  investigative  data 
bate  containing  very  sensitive  information. 

How  does  one  go  about  determining  the  value  in 
dollars  of  such  a  data  basal  The  replacement  cost 
can  be  calculated  by  costing  the  history  of 
investigative  actions  which  supplied  the 
information.  Sometimes  it  is  possible  to  do  this  and 
sometimes  impossible  as  in  tha  ease  of  a  data  baat 
built  up  over  year*;  however,  the  loose*  go  beyond 
almplt  replacement.  Conaonly,  compromise  of 
investigative  information  can  result  in  thwarting  an 
agency  mission  by  divulging  the  confidential  aourcaa 
and  methods  used  by  the  government  to  develop  the 
csee.  In  addition,  there  may  be  political  and 
legislative  repercuaaione  which  often  interact  in 
unexpected  ways. 

Estimating  tha  frequency  of  an  action  ia  also 
difficult  ehiafly  because  there  are  few  solid 
histories  available.  Certain  sources  are  available; 
for  example,  the  Justice  Department's  Bureau  of 
Justice  Statistics,  the  FBI,  and  some  national  trade 
organizations  can  give  information  on  occurrence*  of 
blu*  and  whlta  collar  crime.  Yet,  aggregating 
numeroua  atatiatlcal  sources  which  only  partially 
address  tha  apecific  circumstances  at  hand 
necesaarily  lesaens  predictive  ability. 

Both  astimating  coat  and  determining  threat 
event  occurrence  frequencies  are  processes  which 
cannot  ba  carried  out  in  iaolation.  The  procaaa  ia 
usually  tha  culmination  of  numerous  diacuaaiona  with 
principals;  analysis  of  document.,  budgets  and  plana; 
and  a  considerable  amount  of  estimation.  Tha 
tentative  figures  developed  by  the  analyst  must  be 
defended  to  management  who  may  apply  the  "reasonable 
man"  argument  to  them.  This  argument  suggests  how  a 
reasonable  man  or  disinterested  third-party  might 
view  the  realism  of  the  analyst's  numbers.  Often, 
the  reasonable  man  argument  would  more  honestly  be 
described  as  the  organizational  man  argument. 

Philosophically,  the  objaction  to  the  ALE  method 
canters  upon  the  meaning  of  expected  lose.  The 
mathematical  notion  of  expected  value  allows  one  to 
calculate  an  average  value  given  both  the  probability 
of  an  event  and  tha  value  of  the  asset.  Yet,  the 
number  of  samples  available  to  calculate  the 
probability  is  often  limited  and  carry  with  ■  a 
large  degree  of  variance  as  to  often  make  the 
calculations  meaningless. 

A  second  objection  concern*  what  information  an 
average  value  has  to  offer  for  a  specific  loaa 
situation.  It  is  based  on  the  average  behavior  of  an 
•vent  drawn  from  a  large  population  of  events. 

Average  value  theory  allowe  on  insurance  company  to 
calculate  what  the  expected  lota  ia  over  e  very  large 
number  of  ineurere  because  each  of  the  inaurara  will 
be  different,  some  claims  will  be  leee  end  eosse 
more.  On  the  whole,  the  Ineurere  can  be  expected  to 
act  in  a  more  or  icaa  randomised  fashion  within  a 
given  act  of  criteria.  Knowing  the  distribution 
function  for  the  inaurara  allow*  tha  inauraneo 
company  to  calculate  the  moan  and,  hanca,  calculate 
ita  expected  lea*  and  adjuat  ita  premiums  accordingly. 

Over  the  entire  Maple  el  computer  centers  there 
may  he  a  give*  sample  dlatributlen  which  indicate# 
government-wide  oho*  the  dioMDMHo*  rf  M*t  Jt* 
lath  individual  caia  can  be  empeeted  te  be  different; 
seme  of  mere  end  leeaer  degree,  like  the  ineuranee 
company  of  the  above  example  it  will  be  peeeible  te 
calculate  an  average  and  detdraine  average  leee  for 
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that  population  but  what  does  it  say  about  tha 
individual  eaaat  Xn  turn,  All  nay  bo  likened  to  a 
gambling  strategy  in  which  management  beta  that  an 
event  "la  on  the  average"  no  worae  than  expected. 

A  final  difficulty  experienced  uaing  the  ALE 
approach  la  that  it  producea  a  different  level  of 
protection  for  each  information  aaaet  to  which  it  ia 
applied.  Thia  often  leada  to  a  fragmented  approach 
to  protection  and  doea  not  produce  a  general  eat  of 
protection  mechanism*  available  for  future 
information  ayetema  placed  upon  the  hoat. 

Tha  eecond  atop  in  an  information  aeeurity 
program  for  the  unciaaaifiad  civilian  aganciea  ia  to 
develop  a  email  number  of  uniform  claaaea  for  aaaet 
value  and  protection. 


The  firat  a tap  in  determining  the  level  of 
protection  ia  to  create  an  aaaet  meaeurament  value 
aye tern.  A a  diacueeed  before «  two  approachea  are 
poaalble— the  military  claaaifleatioA  hierarchy  and 
the  civilian  ALI  method.  For  purpoeee  of  thia  paper, 
we  have  adopted  a  ayatea  which  eonforma  roughly  to 
the  military  hierarchy  but  without  the  national 
aeeurity?  implication#  which  ia  preaented  below. 


Military  Claaalf lcatlon 

Unciaaaifiad 

Military  Senaitive 

Confidential 

Sacret 

Top  Secret 

TS/Cetegoriea 


Propoeed  Clvilian.Marklnt 

Non-Sena itive 
Minimally  Senaitive 
Seneltlve 
Sene itive 
Very  Senaitive 
Extremely  Senaitive 


Military  aganciea  arrive  at  a  uniform  definition 
of  value — tha  military  definition  of  security  reliaa 
on  damage  to  the  national  aeeurity  a*  ita  baala.  Tha 
damage  aaaaaamant  definea  a  number  of  levela  named 
confidential,  aacret,  top  aacrat,  and  varioua 
netd-to-knov  groupinga  which  form  tha  familiar 
military  claaalf ieation  hierarchy. 

Thera  ia  alao  a  uniform  degree  of  phyaical 
protection  called  out  in  tha  varioua  military 
aeeurity  doctrlnaa.  Thua,  tha  elamenta  of  tha  ALE, 
aaaat  value,  frequency  of  event,  typa  of  event,  and 
protection  allocation,  are  standardised  for  the 
nntlre  "elaaaified"  community.  This  framework  ia  in 
place  and  what  la  left  is  compliance  determinations . 

Tha  military  doctrine  la  set  up  to 
counterbalance  both  individual  and  aopl.iaticated 
threats  and  ia  skewed  to  a  worat  caae  analyaia  of  tha 
threat.  Taking  this  worat  caaa  approach  simplifies 
tha  security  program  because  It  removes  the 
requirement  of  staying  one  atap  ahead  of  any  threat 
which  may  evolve  01.  short  notice.  Thera  are  great 
operation  advantages  to  thia  ilmplifiad  approach  if 
funds  are  available. 

In  comparison,  the  civilian  sector  commonly 
requires  tha  protection  system  to  expend  only  enough 
to  counter  the  average  threat  facing  it.  Tha  threat 
anvlronawnt  facing  civilian  sector  aganciea  ia  much 
more  stable  and  unchanging  than  tha  one  facing 
national  aeeurity  eatebliahmentei  hence,  ae  in  life 
ineurance,  the  gamble  ia  that  tha  agency's 
information  protection  approach  can  bound  aeeurity 
risk  problems  on  the  average. 

A  pressing  disadvantage  of  thia  approach  ia 
that,  to  data,  no  uniformed  claaalf ieation  syatam  has 
baan  advanced  for  tha  unclassified  civilian  lector 
which  could  allow  tho  streamlining  of  protaction 
programs.  If  a  uniformed  lavel  of  protection  and 
threat  similar  to  the  military  olasalf ieation 
hierarchy  were  available  and  suitably  diractad  toward 
a  civilian  agancy'a  thraata  and  If  it  raotlvad  tha 
right  recognition  from  the  Executive  Branch, 
information  aeeurity  might  be  advanced  eeroea  the 
entire  federal  olvllian  aector. 

LEVEL  Of  PEQT10T10N8 


Thia  ahowa  a  four-level  value  aaaet  hierarchy 
with  approximate  correspondence  to  the  military 
claaalf icationa.  It  ia  Important  to  note  that  thia 
chart  ahowa  aaaat  worth  by  tha  damage  a  compromise 
could  do  rather  than  assigning  a  dollar  value  to  tha 
asset  aa  tha  ALE  would  suggest. 

The  difference  between  military  senaitive  and 
minimally  aanaltive  ia  that  the  term  "sensitive"  la 
currently  uaad  by  military  and  national  security 
organisations  to  denote  unciaaaifiad  information 
which  impacts  aspects  of  the  national  security,  but, 
hereto,  has  bean  considered  unclaaiif led. 

Information  in  thia  category  includes  national  and 
international  financial  trends  and  projections, 
movement  and  supply  of  strategic  material,  force 
readlneaa  eatimatlona,  poaltlona  for  international 
treaty  negotiations,  and  similar  information.  The 
civilian  treatment  of  the  term  sensitive  ia  more  in 
line  with  the  overall  sensitivity  of  the  information 
in  a  domestic  context.  Items  covered  under  the 
civilian  usage  of  the  term  would  be  Information 
specifically  protected  by  law,  such  ae  grend  jury 
testimony;  identities  of  confidential  informante;  tax 
return  data;  and  agency  senaitive  Information,  such 
aa  eonfldantial  correspondence,  financial 
decision-making  or  disbursement  data,  and  employee 
salary  or  medical  histories. 

Tha  highest  category  in  this  chart  la  extremely 
senaitive  and  it  has  baan  equated  with  the  military 
usage  of  top  secret  with  categories.  It  is  felt  that 
the  aenaltivity  of  thia  information  greatly  exceeds 
that  which  would  be  considered  very  senaitive.  No 
commercial  operating  system,  enhanced  or  otherwise, 
not  specif icaliy  designed  for  the  A  class  should  ba 
considered  adequate  for  thia  type  of  information  and, 
hence,  it  must  be  compartmentad  and  run  on  a 
dedicated  ayatea,  It  is  not  economical  to  run  such 
information  In  a  shared  node,  and  tha  risk  from  other 
users,  which  ia  difficult  to  estimate  In  moat  normal 
cases ,  would  be  unacceptable  in  this  oaea. 

The  ratings  displayed  in  tha  aenaltivity  marking 
table  are  designed  to  be  used  on  all  civilian  agency 
information,  especially  computer  systems.  Having 
four  levels  whoa#  value  la  recognised  across  all 
civilian  ageneiac  appears  to  ba  helpful  to  tha 
planning  and  budgeting  process  aa  wall  because  it  now 
dearly  state*  the  value  of  tha  data. 


Establishing  layals  of  protection  entails 
creating  a  map  between  value  of  a  aaaat,  the  degree 
if  trust  far  paraewtal ,  and  tha  resulting  amount  at 
trustworthiness  needed  Iran  tha  aaftvtra.  The  mod* 
at  egurafclaa  i»  tnpirtw  **  wall,  and  far  purpose* 
of  nit  paper,  tsa  oelti-ienaitivlty  shared  code  ia 
assumed.  Other  mode*  such  as  dedicated,  or  ayatea 
high  mad*,  aadlfy  tha  balance  and  threat  environment 
and,  thereby,  require  a  somewhat  modified  analysis. 


the  next  atap  U  establishing  a  level  at 
protection  plan  la  to  establish  a  ayatea  for  user 

Jruot  and  access.  Tha  Office  of  forioaaol  Management 
ha*  adwwaad  a  arete*  of  tiumtii  tor  the 
civilian  agendas  which  ia  similar  in  scape  to  tha 
military  clearance  structure  which  ia  shewn  below; 


II 


Military  Proposed  Civilian 

Information  Information  0PM  Personnel 

Classlf ication  Claaalf lcatlon  Clearances 

Uncleared  Mon-Sensitive  Non-Sensitive  (NS) 

Military  Sensitive  Minimally  Sens  it ive  Non-Crit ical 

Sensitive  (NCS) 

Confidential  Sensitive  Non-Critical 

Sensitive  (NCS) 

Secret  Sensitive  Non-Critical 

Sensitive  (NCS) 

Top  Secret  Very  Sensitive  Special  Sensitive 

(SS) 


There  are  two  vers  Iona  of  C2  mentioned  in  this 
chart;  C2-a  ("augmented")  and  C2-ae  ("augmented"  and 
"enhanced") •  The  chief  difference  between  these  two 
is  that  C2-ee  auggeata  tha  use  of  privacy  encryption 
(DES)  on  all  very  aenaitlve  information. 

Additionally,  encryption  would  be  applied  to 
files  and  used  to  provide  a  higher  degree  of  access 
control  and  authentication  abova  chose  commonly 
required  by  C2.  Encryption  of  data  without  a  firm 
base  of  trusted  software  surrounding  it  limits  its 
ability  to  withstand  attack;  however,  it  la  a  tool 
which  should  not  be  ignored,  especially  in  that 
multilevel  trusted  systems  may  not  be  available  in 
the  near  future,  especially  for  the  civilian  sector. 

TCB  CLASS  C2  AND  ENH ANCEMENTS 


Top  Secret  Extremely  Sensitive  Critical  Sensitive 

Categories  (CS) 

The  mapping  of  the  0PM  clearance  structure  to 
civilian  information  classifications  and  the  military 
classification  hierarchy  is  simply  an  initial  attempt 
at  establishing  such  s  system.  Many  civilian 
agencies  currently  require  the  0PM  clearances  for 
their  computer  staff,  commonly  the  higher  clearances, 
because  of  the  wide  types  af  information  which  they 
handle.  Users,  such  as  data  entry  contractors  or 
clerical  personnel,  usually  require  either  the 
non-crltlcal  sensitive  or  special  sensitive, 
depending  upon  the  sensitivity  of  the  information 
they  are  handling.  Extremely  sensitive  information 
and  its  0PM  clearance— Cri  t ical  Sensitive — are  used 
for  specialized  personnel  handling  the  most  sensitive 
data. 

The  last  step  in  creating  the  mapping  of  value, 
access,  and  protection  is  to  create  a  mapping  between 
value,  exposure,  and  software  protection. 

A  suggested  ranking  for  the  unclassified 
sensitive  world  is  shown  below. 


Civilian 

Information 

Classification 

TCB 

Class 

Mode  9 f  Ope  ra  t  ion 

Extremely  Sensitive 

Cl 

Dedicated 

Very  'Sensitive 

C2 

C2-ae 

System  High 
Shared-mul t i leve 1 

Sensitive 

r2 

C2-a 

System  High 
Shared-muiti level 

Minimally  Sensitive 

C  2 

There  are  four  entries  in  this  table  which 
indicate  tha  four  levels  suggested  previously. 

Column  3  indicates  the  mode  of  operation.  There  are 
three  mode*  indicated  here:  dedicated,  system  high, 
and  ehared-multl level .  First,  dedicated  mode 
describe*  the  case  where  the  available  hardware  and 
software  are  not  secure  enough  to  guarantee  good 
security.  This  mode  is  reserved  for  the  most 
sensitive  missions. 

While  we  have  indicated  a  Cl  "group"  style 
environment  being  adequate,  prudent  administration 
should  call  for  anti-fraud  and  anti-white  collar 
crime  mechanisms  to  monitor  and  control  tha  use  of 
information  by  eloartd  ompleyoos. 


The  NCSC  guidelines  specify  a  C2  class  system  as 
the  minimum  protection  strategy  for  unclassified 
information  which  requires  need-to-know  separation. 
Additionally,  the  NTISSC  staff  has  set  C2  as  a  target 
for  federaL  agencies.  This  is  a  necessary  but 
difficult  task  for  many  federal  agencies,  but  it  must 
be  pointed  out  that  C2  may  be  inappropriate  for 
certain  sharing  situations.  Primarily,  these 
situations  involve  multi-sensitive  sharing  between 
information  systems  which  hold  very  sensitive 
information  and  those  which  information  systems  used 
to  store  minimally  sensitive  information  on  the  same 
mainframe . 

A  very  high  reverse  correlation  in  civilian 
agencies  between  the  amount  of  information  to  process 
and  its  sensitivity  is  almost  an  exponential 
relationship.  As  described  previously,  the  lower  the 
sensitivity,  the  lower  the  clearance  levels  and 
looser  the  security  administration  in  general. 

There  are  three  reasons  for  looser  security 
controls  in  these  lower  sensitivity  systems.  First, 
authentication  and  access  control  restrictions  are 
relaxed  in  favor  of  getting  the  job  done.  In  the 
second  case,  administering  very  large  numbers  of 
users  who  report  to  different  chains  of  command  and 
are  distributed  over  large  distances  is  very 
difficult.  These  leave  numerous  opportunities  for 
abuse  of  passwords  and  access  privileges. 

Third,  there  la  a  tendency  for  users  to 
accumulate  file  access  privileges  awarded  for  files 
or  file  categories  in  order  to  meet  a  particular 
need,  which  are,  however,  not  surrendered  and  simply 
accumulated.  Thus,  it  is  not  uncommon  to  find  users 
with  access  rights  to  large  portions  of  a  system 
without  a  current  need-to-have  for  these  accesses. 

While  these  problems  can  be  solved  with  good 
security  management  practices,  it  must  be  recognized 
that  decentralized  and,  hence,  fragmented  security 
administrations  do  exist.  It  is  also  unreasonable  to 
suggest  that  the  situation  will  change  dramatically 
In  the  near  timeframe.  Sharing  computer  resourcei 
among  a  large  population  of  user*  will  bring  with  it 
a  higher  risk,  precisely  tha  situation  addressed  by 
the  NCSC  guideline*  for  classified  usare. 


What  ie  proposed  it  the  development  of  e  new 
middle  clast  between  C2  and  51  which  would  contain 
many  of  tha  stronger  feature*  of  51  but  would 
continue  to  rely  on  non-mandatory  access  control 
structurts  in  favor  of  the  lower  cost  rule-based 
access  control  packages.  Tha  proposed  elat*  la 
labeled  C2-a,  which  lor  dlscuaaion  purposes  would 
ssrve  as  an  Interim  step  (or  the  civilian  aienclaa 
until  stronger  multi-level  systems  were  svelleble 
from  the  Evaluated  Product*  List  (IPL)  et  e 
reasonable  cost.  Whils  not  fully  developed,  the 
major  requirements  of  C2-a  ar*  outlined  below, 


There  it  a  fundamental  breakpoint  in  the  TCB 
between  the  C2  and  B  eiatt  of  systems  which  it  teen 
in  all  the  security  requirement  treat.  Thia 
demarcation  it  reflected  in  a  number  of  wayt.  the 
most  obvious  of  which  it  that  Clatt  B1  it  the  first 
class  where  mandatory  controls,  labels,  and  a 
security  policy  are  required.  Comparatively,  Claes  C 
need  provide  only  discretionary  controls. 

A  second  important  differencs  Is  the  sbillty  of 
the  system  to  withstand  penetration.  Clast  C2 
requires  that  obvious  flaws  be  identified  and  removed 
while  Class  Bl  requires  detailed  study  of  the 
operating  system  code  in  addition  to  the  required 
live  testing.  Elimination  of  obvious  flaws  required 
by  C2  leaves  numerous  more  subtle  flaws  untreated, 
yet  Bl  requires  these  to  be  removed.  A  skilled 
attacker  could  find  a  C2  system  susceptible  to 
penetration  by  flaws  which  might  be  well  known  in  the 
system  programming  community.  Class  Bl  requires 
these  flaw9  to  be  removed. 

Above  those  required  for  Class  C2,  improvements 
required  by  C2-a  are  Improved  audit  trails,  better 
access  policy,  markings  on  mul t i-sens l t iv l ty  computer 
output  devices,  and  a  private  address  space  for  the 
system  s.curity  mechanism.  Each  will  be  discussed 

below. 

First,  improved  audit  trails  are  critical  to 
good  security  since  they  frequently  provide  the  only 
record  of  what  actions  occurred  during  a  security 
breach.  They  have  proved  decisive  in  locating  and, 
in  some  cases,  prosecuting  an  offender  and  should  be 
carefully  designed  on  a  new  system.  There  are  two 
modes  of  analysis  of  an  audit  tra  1 1!  post-mortem  and 
defensive  analysis. 

Post-mortem  analysis  takes  place  when  a  security 
breach  has  occurred  nnd  a  time  history  is  being 
assembled  of  the  event.  Participating  in  such  a 
post-mortem  reconstruction  Is  often  the  best  teacher 
of  what  Information  to  include  in  an  audit  trail  and 
hew  it  should  be  organized.  Since  the  audit  trail 
may  be  introduced  as  part  of  a  court  proceeding,  its 
designers  should  also  have  a  knowledge  of  the  rules 
of  evidence. 

Defensive  analysis  occurs  by  systematic  analysis 
of  the  audit  information  on  a  routine  basis.  This 
allow*  a  security  officer  to  identify  suspicious 
activity  as  it  happens.  Frequently,  too  much 
irrelevant  data  la  available  preventing  any  serious 
analysis  of  the  audit  information.  Some  researchers 
have  suggested  employing  artificial  intelligence 
techniques  to  automatically  analyse  the  audit 
information  for  problems. 

Baslde  acting  as  one  of  the  reliable  records  of 
past  events,  the  knowledge  of  the  existence  o'  a 
well-designed  audit  trail  deters  white  collar 
criminals"  by  simple  surveillance  of  the  system. 

This  increases  the  certainty  of  balng  caught  and 
successfully  prosecuted.  In  sum,  an  enhanced  end 
well-designed  audit  trail,  together  with  analysis 
tools,  Is  cartainly  neceesary  in  any  multi-level 
sharing  endeavor. 

The  second  requirement  of  C2-a  ie  improved 
security  policy.  It  ie  first  necessary  to  compile 
and  have  approved  an  agency-wide  security  policy.  In 
thia  paper  we  have  advanced  using  the  four  levels  of 
sensitivity  as  s  starting  point,  federal  law, 
executive  orders,  special  department-wida 
Instructions,  and  agency  orders  often  form  other 
access  restriction*.  In  addition,  many  agoncloa  also 
partition  aecsss  by  program  and  project. 


Accoae  control  packages  are  baginning  to  include 
provisions  for  controlling  dsts  bass  snd  transaction 
monitor  file  access,  yst  many  projects  are  reluctant 
to  surrender  thalr  privileges  to  a  central 
authority.  A  way  around  thia  dilemma  it  to  uae  local 
projact-orientad  access  rule  managers  in  addition  to 
the  computer  center  security  administrator.  Each 
access  rule  manager  would  have  responsibility  to  his 
own  project. 

A  useful  extension,  which  currently  does  not 
exlet,  would  be  a  rule  protocol  which  allowed  each 
party  to  ltvy  constraint*  on  what  kind  of  acetates 
can  be  granted.  Thus,  the  computer  center  stcurlty 
officer  could  restrict  the  local  acceaa  rule  manager* 
from  adding  new  account*  to  the  system,  while  the 
local  acceaa  rule  manager  could  restrict  the  security 
administrator  from  granting  access  to  file*  under  hie 
jurisdiction.  Split  granting  authority,  special 
authorization  digital  signatures,  and  other  devices 
including  anti-fraud  aides  might  be  included  to 
create  a  rule-based,  power-sharing  structure  to  meet 
the  needs  of  any  two  parties,  cooperative  or 
distrustful . 

The  third  item  necessary  for  enhanced  sharing 
mode  is  sensitivity  markings  on  multi-sensitivity  I/O 
devices  and  the  labeling  of  input  and  output 
hard-copy.  This  requirement  is  chiefly  to  avoid 
mishandling  of  hard-copy  input  and  output  media  and 
to  ensure  proper  control  of  terminals.  Many  large 
computer  centers  commonly  have  large  printer  bays  in 
which  a  number  of  high-speed  printers  are  used. 
Printouts  are  commonly  routed  to  a  printer  based  or. 
the  type  of  paper  in  the  printer,  for  example, 
multi-part  "carbon"  paper.  It  is  quite  typical  to 
find  computar  canters  routing  jobs  of  various 
sensitivities  to  a  printer  depending  upon  the  paper 
forms  needed.  Thus,  very  sensitive  printouts  are 
handled  as  non-senai t ! ve  until  received  by  the  I/O 
control  clerk.  Additionally,  items  like  memory  dumps 
are  typically  not  controlled  at  the  level  of  the  data 
they  contain. 

Formal  object  labels,  user  clearance  data  bases, 
and  reference  monitors  are  the  heart  of  a  mandatory 
access  ccntrol  structure.  To  have  a  reference 
monitor  at  all  seems  to  require  object  labeling  and, 
by  implication,  a  user  clearance  data  base  to  allow 
the  reference  monitor  to  apply  the  security  model. 

It  is  a  matter  of  disagreement  at  thia  point  whether 
an  access  control  package  can  suffice  for  enhanced 
sharing  or  if  indeed  the  full  suit  of  labels, 
reference  monitors,  and  clearance  data  base*  are 
requi red . 

If  other  requirements  can  he  satisfied,  then  it 
stems  adequate  to  settle  upon  an  enhanced  rule-bated 
access  control  system  to  enforce  sharing.  The 
strength  of  the  mandatory  acceaa  ia  it*  ability  to 
mediate  all  accesses  at  a  basic  level.  At  the  Bl 
level  the  required  assurance*  are  not  yet  developed 
to  the  point  where  multi-level  sharing  can  be  trusted 
as  is  the  case  in  a  B2  environment.  Therefore,  the 
essential  aapect  is  the  raferenc*  monitor's  ability 
to  mediate  all  accesses.  Within  the  C2~a 
environment,  an  anhaneed  rule-based  eecaea  control 
package  might  be  adequate. 

Lastly,  a  requirement  for  multi-level  sharing  la 
that  the  security  mechanisms  not  he  subvartabl*  by  e 
malicious  user.  One  of  the  beet  wtye  to  do  thle  la 
to  place  tho  aecsss  control  mechanism  In  Its  own 
addross  apace  end  teko  measures  to  protect  critical 
information  that  It  uaea,  luma  access  control 
packages  share  certain  resarved  system  address  apace 
virtual  memory  along  with  other  special  routine*  end 
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the  operating  system.  Information  modification) 
either  by  a  trojan  horae  routine  Included  within  the 
operating  aye tern  or  commercial  package  or  an 
inadvertent  modification  due  to  an  error,  could 
diarupt  the  acceaa  control  mechaniam.  further 
reaearch  would  be  needed  to  determine  the  extent  of 
thia  vulnerability  in  the  open  ayatem  environment 
common  in  civilian  agency'a  data  centare. 

Thia  section  has  outlined  the  argument  for  an 
enhanced  level  of  protection  beyond  the  C2  level  but 
without  some  of  the  structures  required  for  the  B 
class.  The  C2-a  class  was  advanced  to  support  cases 
where  very  sensitive  information  is  handled  within 
the  lame  commercial  mainframe  and  operating  system  in 
the  presence  of  numerous  minimally  cleared  or 
controlled  uaers. 

C2-a  would  contain  stronger  resistance  to 
penetration  than  C2  by  elimination  of  subtle  flaws. 
C2-a  operating  system*  would  have  enhancements  of 
their  audit  trail  capabilities,  access  control  down 
to  the  information  system-owned  file  level,  and 
output  marking  capabilities.  In  sum,  each  of  these 
measures  reduces  some  aspect  of  risk  associated  with 
multi-sensitivity  sharing  and  is  proposed  as  an 
Interim  step  which  could  be  accomplished  by  the 
civilian  agencies  sector  until  more  products  become 
available  on  the  EPL.  The  discussion  of  C2-a 
presented  here  is  simply  an  overview  of  the 
requirements  the  proposed  class  would  need. 

Additional  research  would  be  needed  to  clearly  define 
all  aspects  of  this  proposed  class. 

CRYPTOGRAPH  I C  FILE  PROTECTION 

An  often  overlook  technique  of  protection  for 
multl-sensltlvlty  sharing  is  file  encryption^. 

File  encryption  is  not  currently  considered  useful  In 
satisfying  the  requirements  of  the  trusted  computer 
base  and  has  been  partially  neglected  in  favor  of  a 
trusted  software  approach.  File  encryption  is  still 
useful  for  providing  en  extra  layer  of  safeguard  in  a 
computer  ayatem  and  is  suggested  as  an  additional 
security  tool  for  multi-sensitivity  sharing 
situations. 

File  encryption  is  attractive  because  it  is  one 
of  the  only  means  available  to  prevent  even  a  skilled 
system  programmer  from  browsing  stored  information. 

It  is,  therefore,  attractive  to  organisations  with 
tha  most  sensitive  data.  File  encryption  prevents 
browsing  by  user  organisation  members  with  general 
authorisation  to  view  all  files  within  their 
organisation  except  specific  ones. 

There  are  four  major  points  to  consider  in 
selecting  a  file  encryption  technique  for  the  C2 
level! 

e  Cryptogrephic  encoding  method 

•  Target  file  organisation 

•  Key  management 

•  Trustworthiness  of  the  encryption  routine 

The  first  element  of  file  encryption  la  to 
consider  the  encoding  method.  Cryptographic  encoding 
li  commonly  applied  In  three  waysi 

e  Slock  or  electronic  code  book  mode  In  which 
a  group  of  bit*  which  fora  a  black  are 
enciphered  together  «,.d  the  enciphered 
output  le  a  bleak  ef  similar  site. 


e  Chaining  methods  in  which  sampled  of  plain 
taut  and/or  ciphertext  from  previously 
enciphered  blocks  art  mixed  with  current 
information  during  the  encipherment 
proceaa.  Block  chaining  prtvanta  cartaln 
types  of  spoofing  attacks  but  also 
propagates  errors  across  some  amount  of  data. 

a  Additive  mathod  in  whic..  a  cipher  key  stream 
is  generated  independently  and  combined  with 
the  file  information  on  a  bit-by-bit  baeis. 
Tha  additive  method  has  the  advantage  of  not 
propagating  errors  but  suffers  from  a  need 
for  precise  synchronisation. 

Selection  of  algorithm  for  a  file  encryption 
capability  is  limited  to  NSA-spproved  algorithms  for 
government  use.  Perhaps  the  best  known  example  is 
the  data  encryption  standard  algorithm  (DES)  which  is 
finding  popular  use  In  privacy  applications.  The 
drawback  in  using  DES  is  that  it  is  computationally 
expensive  for  software  implementations,  and  this  must 
be  factored  into  response  time  calculations  for 
interactive  applications. 

MSA  has  advanced  several  new  algorithms  under 
the  Commercial  Cryptographic  Endorsement  Program 
(CCEP).  which  are  targeted  primarily  at  the 
communications  marketplace.  The  Type  II  algorithms 
are  meant  specifically  for  the  unclassified  area! 
they  are  available  only  as  integrated  circuits  to 
approved  manufacturers  and  are  not  available  in 
software  form. 

Thus,  while  DES  will  be  gradually  withdrawn  from 
the  federal  marketplace  In  fevor  of  the  CCEP  Type  II 
algorithms,  no  substitute  has  been  suggested  for 
software  versions  of  DES.  Some  authorities  have 
suggested  thst  e  way  to  approach  the  file  encryption 
problem  la  to  develop  e  fast  hardware  box  containing 
the  CCEP  Type  II  algorithm.  The  "crypto-box"  would 
be  used  «a  e  controlled  peripheral  device  to  a 
computer  system  end  would  provide  a  fatter 
replacement  for  DES.  To  my  knowledge,  no  work  hae 
been  done  to  develop  such  a  box  or  standards  for  its 
use. 

File  organisation  Is  important  to  a 
cryptographic  file  security  tool.  Computer  files 
have  different  record  organisations  such  as 
sequential,  random  access,  relative  record,  Indexed 
sequential,  end  proprietary  methods  developed  by  data 
base  manufacturers.  Fitting  an  encryption  technique 
to  each  specific  type  of  file  organization  is 
necessary  in  that  ciphers  commonly  must  be  started  at 
a  mutually  agreed  starting  point  which  la  difficult 
for  short  end  varying  length  records.  This  is  in 
■ome  respecti  similar  to  the  problem  of  end-to-end 
encryption  in  en  X.25  network  where  each  packet  must 
contain  its  own  initial  fill  value. 

Therefore,  in  providing  e  file  encryption 
package,  each  file  must  be  considered  separately.  In 
archive  cases  where  an  entire  magnetic  tepa  is  to  be 
enciphered,  chaining  schemas  work  well  becauae  of  the 
long  stretches  of  data  while  short  records,  which  ere 
randomly  organised,  require  completely  different 
enclpherlni  methods.  The  requirement  for  flexibility 
preclude!  a  rigid  single  format  end  some  adaptable 
techniques  ere  required,  perhaps  as  a  set  of 
aubroutlne  calls  to  e  "trueted"  encryption  facility. 

Key  management  le  the  third  acpect  ef  a  file 
encryption  technique.  Thia  ia  perhaps  one  of  the 
moat  difficult  ereae  to  surmount  because  of  its 
crucial  nature.  The  nature  ef  the  current  modern 
information  eycteme  is  to  provide  eeoeee  online  to 


numerous  Individual*  sometimes  distributed  over  a 
wide  geographical  area.  Key*  must  be  distributed  to 
each  of  these  parties,  and  the  number  of  issued  keys 
would  grow  quite  large.  Indeed,  what  we  are  faced 
with  here  is  s  problem  not  unlike  that  of  a  secure 
packet  twitching  system  in  which  keys  grow 
exponentially  with  the  number  of  network  nodes. 

The  solution  advanced  with  the  packet-switching 
n.:works  and  which  may  have  application  for  a  file 
encryption  tool  Is  a  key  distribution  facility 
(KDF).  The  role  of  the  KDF  would  be  to  enforce  an 
access  protocol  on  each  user,  perhaps  employing  a  key 
shared  between  the  KDF  and  the  user.  The  actual  file 
encryption  key  would  not  be  shared  with  the  user  but 
might  be  derived  from  the  user's  key,  a  file  key,  and 
perhaps  a  local  security  key. 

Design  of  such  a  system  and  Indeed  its  protocol 
will  need  development  while  Implementation  could 
employ  either  conventional  key  management  techniques 
or  perhaps  public  key  ideas,  it  appears  that  the  KDF 
Idea  will  probably  prove  a  way  to  solve  this 
difficult  problem, 

Lastly,  assurance  is  the  fourth  issue  in  design 
of  a  strong  file  encryption  technique.  We  are  faced 
with  a  problem  similar  to  developing  trusted  software 
for  the  TCB  in  that  the  techniques  are  similar.  It 
is  for  this  reason  that  the  C2-a  system  proposes 
stronger  penetration  testing  than  simply  elimination 
of  obvious  flaws  found  in  C2  requirements.  Yet, 
thete  is  a  delicate  tradeoff  required  In  arriving  at 
a  balanced  assurance  level  for  the  file  encryption 
tool . 

File  encryption  can  provide  good  privacy  and 
authentication  methods  when  there  Is  high  risk  and 
when  other  techniques  are  unavailable.  File 
encryption  Is  not  being  discussed  here  as  a 
replacement  for  trusted  software  chiefly  because  It 
fills  a  somewhat  different  function  and  serves  as  a 
useful  adjunct.  In  sum,  the  techniques  and  products 
for  file  encryption  on  unclassified  sensitive 
computer  systems  are  not  as  well  developed  as  one 
would  wish)  however,  It  Is  one  of  the  proven  tools 
which  are  available  where  other  forms  of  risk 
reduction  ate  not  available. 

CONCLl'SIpN 

This  paper  has  presented  a  discussion  of 
security  factors  affecting  unclassified  sensitive 
civilian  agency  systems. 

The  multi-sensitivity  sharing  problem  was 
reviewed  and  two  essential  questions  were  proposed: 
first,  can  the  information  system  adequately  control 
ths  users  authorised  to  ust  it,  and  second,  can  th* 
operating  system  prevent  users  of  one  information 
system  from  accessing  files  and  resources  of  some 
other  system?  It  was  shown  that  both  these  Issues 
cannot  be  given  an  unqualified  answer  lacking 
multi-level  trusted  software!  yat,  It  is  possible  to 
substantially  rsduca  the  risk  of  multi-sensitivity 
sharing  by  good  software  security  engineering  and 
basic  security  enhancements  to  ths  operating  system. 

In  this  respect  ths  notion  of  an  snhsncsd 
varaion  of  th*  basic  C2  requirements  was  advanced 
with  ths  goal  of  introducing  improvement*  to  battsr 
manage  a  multi-sensitivity  job  stream  and  improve  ths 
system's  resistance  to  panstrttlon.  Additionally, 
file  encryption  was  suggested  as  t  further  way  to 
limit  risk  In  systems  whar*  thsrs  is  s  large 
difference  between  th*  lowest  clearance*  and  ths 
highest  classification  of  data. 


Primarily,  the  C2-a  suggestion  is  viewed  as  an 
interim  step  which  could  provide  better  security  in 
the  period  until  true  multi-level  products  are 
available  from  the  EPL  at  a  Juatifiabla  cost.  This 
msy  be  a  considerable  period  of  time  because 
researchers  and  manufacturers  are  targeting  the 
claetlfied  market  first. 

Lastly,  It  is  Important  to  not*  the  difference 
In  culture  between  military  and  civilian  agencies. 
Each  has  evolved  in  a  culture  facing  significantly 
different  problems  and,  hence,  responses  and 
perceptions  are  different.  If  the  body  of  military 
security  knowledge  Is  to  be  of  value  to  civilian 
agenciei,  it  must  begin  by  reformulating  ita 
associated  doctrine  of  use.  Security  programs  which 
do  not  conform  to  an  organisation's  culture  will 
ultimately  be  expensive  to  administer  and  vulnerable. 
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Abstract 

In  thli  paper  th«  formal  verification  of  com* 
putar  systems  and  software  Is  viewed  as  an  en¬ 
deavor  In  applied  mathematics.  It  Is  argued  that  a 
formal  verification  should  consist  of  three  separate 
but  Interacting  processes:  a  modelling  process,  a 
theorem  proving  process,  and  a  review  and  accep¬ 
tance  process.  Suggestions  are  made  for  Improv¬ 
ing  the  development  of  these  processes.  Taken 
together,  they  outline  a  proposed  discipline  for 
the  development  of  verified  software.  The  Ideas 
prssented  were  principally,  though  not  exclusively, 
motivated  by  the  authors'  work  In  reviewing  the 
design  verification  of  the  Restricted  Access  Pro¬ 
cessor  (RAP).  Examples  are  drawn  from  the  RAP 
verification  to  support  our  suggestions  for  Improv¬ 
ing  formal  verification. 


1.  INTRODUCTION 

The  main  purpose  of  this  paper  is  to  propose  a  dis¬ 
cipline  for  the  development  of  verified  software.  Our 
comments  in  thia  paper  are  motivated  in  part  by  our 
recent  experience  reviewing  the  design  verification  of 
the  Reitricted  Access  Proceeeor  (RAP)  (cf.  |3j,  (7j). 
We  also  draw  some  examples  from  the  RAP  verifica¬ 
tion  to  support  our  views.  The  paper  attempti  to  de¬ 
scribe  verification  as  an  endeavor  in  applied  mathemat¬ 
ics.  Though  this  viewpoint  is  not  completely  new  (cf. 

(1],  (10|)  and  might  even  be  regarded  as  the  obvious  one 
to  take,  from  our  review  experience  we  are  led  to  be¬ 
lieve  that  the  exact  consequences  of  taking  this  view  are 
not  fully  and  clearly  understood.  In  particular,  perceiv¬ 
ing  verification  as  applied  mathematics  requires  a  clear 
differentiation  between  the  following  two  processes: 

(1)  Sttablukiny  formal  motktmotiiol  models  of 
aeturaMenfuag*  rtgetremenle  or  opooifiootiom,  In 
the  case  of  design  verification  for  secure  systems, 
these  models  are  usually  called  Mis  formal  secu¬ 
rity  model  and  the  (formal)  top  level  specification 


(TLS).  We  refer  to  this  as  the  modelling  process, 
which  in  our  view  is  perhaps  the  most  critical  part 
of  the  verification,  yet  it  is  apparently  the  least 
understood. 

(2)  Ur  inf  mathematical  trthniquu  to  reaeon  about  the 
formal  models  obtaintd  by  the  modelling  proceee.  In 
the  design  verification  of  the  RAP,  this  reduced  to 
proving  formally  that  the  TLS  satisfied  the  formal 
■ecurity  model.  We  call  this  the  theorem  proving 
process. 

We  realised  in  our  review  of  the  RAP  that  the  dis¬ 
tinction  between  the  modelling  process  and  the  theo¬ 
rem  proving  process  is  especially  important  from  the 
reviewer'*  perspective,  eince  the  task*  Involved  in  each 
of  these  processes  are  to  be  understood  and  judged  in 
very  different  way*.  Yet  while  theae  proceiaee  are  dis¬ 
tinct,  it  is  inevitable  (and  dsfinitely  beneficial  for  the 
verification)  that  they  will  interact  with  one  another. 

In  addition  to  these  two  processes  wa  bsliava  that  it 
is  useful,  in  analogy  with  similar  validation  processes 
occurring  in  the  mathematical  sciences,  to  include  a 
third  interacting  process  as  well: 

(3)  Reviewing  and  accepting  tk*  vtrifieation,  Gener¬ 
ally,  this  means  ascertaining  that  the  verification 
satisfies  requirements  agreed  upon  by  the  customer 
and  the  verifier.  Requirements  may  include,  for  ex¬ 
ample,  the  use  of  automated  tools.  Another  rele¬ 
vant  and  more  important  requirement  is  soundness 
of  the  logical  principles  used  in  the  verification  In 
our  view,  part  of  the  review  process  should  allow 
for  interaction  between  the  reviewers  and  the  ver¬ 
ifiers. 

W*  gratefully  acknowledge  the  support  of  the 
Rome  Air  Development  Center  under  contract  number 
P  IMM-M-O-OQOl  during  the  preparation  of  this  paper. 
We  would  also  like  to  thank  B.  Beasley,  J.  Milica,  P. 
Tasker,  and  l  WOUame,  who  offMed  guidance  in  the 
formulation  of  the  ideas  presented  bt  thia  paper. 


2.  THE  MODELLING  PROCESS 

Mathematical  modelling  is  a  crucial  process  in  the 
task  of  formal  verification.  For  example,  in  the  verifi¬ 
cation  of  secure  systems,  a  formal  security  model  for 
the  security  policy  is  constructed  or,  in  some  cases, 
provided  (e.g.,  the  Bell-LaPaduia  security  model).  In 
this  section  we  discuss  various  aspects  of  the  modelling 
needed  in  verification,  using  our  findings  from  reviewing 
the  design  verification  of  the  RAP  to  develop  examples 
and  special  points. 

In  general,  models  provide  a  description  of  seme  real- 
world  phenomenon.  By  “phenomenon*  we  mean  some¬ 
thing  very  general.  A  phenomenon  may  be  a  process  or 
a  system;  even  a  natural  language  description  of  a  sys¬ 
tem  or  process  is  a  phenomenon.  A  fundamental  aim 
for  constructing  a  model  is  to  allow  the  use  of  formal  de¬ 
ductive  techniques  on  the  model  to  gain  some  new  infor¬ 
mation  or  conclude  something  about  the  phenomenon. 
This  aim  requires  that  models  be  comprehensive  in  the 
sense  that  they  contain  all  information  necessary  for 
applying  these  formal  techniques.  It  should  be  empha¬ 
sised  that  formal  deduction  is  clearly  distinguished  from 
other  forms  of  evidence,  such  as  empirical  evidence,  so 
that  the  requirement  of  comprehensiveness  is  quite  im¬ 
portant. 

Another  highly  significant  aim  of  the  modelling  pro¬ 
cess  is  to  make  the  phenomenon  intelligible  to  others. 
In  order  to  achieve  this,  the  models  have  to  be  clear  and 
thoroughly  explained.  Models  that  resemble  computer 
code  do  not  meet  these  goals. 

The  process  of  building  useful  models  is  one  of  the 
most  difficult  in  all  of  science.  The  model-builder  has 
first  to  select  carefully  the  tools  and  techniques  from 
mathematics  that  seem  the  most  appropriate  for  pre¬ 
senting  the  model.  Most  critically,  he  must  decide  how 
to  represent  elements  of  the  phenomenon  with  mathe¬ 
matical  constructs. 

The  model  should  be  a  clear  portrayal  of  the  phe¬ 
nomenon,  so  that  if  can  be  accepted.  Acceptance  of 
a  model  is  based  on  the  collective  experience  of  the 
researchers  doing  modelling  and  also  on  subjective  fac¬ 
tors,  such  as  mathematical  taste.  A  precept  that  is 
universally  true  is  that  models  are  meant  to  be  under¬ 
stood.  Questions  of  style  and  format  are  not  to  be 
brushed  aside  as  technically  irrelevant.  Moreover,  spe¬ 
cific  sciences  have  developed  special  methodologies  for 
validating  models.  These  methodologies  generally  rely 
on  experimentation  and  statistical  sampling;  even  some 
form  of  disciplined  introspection  may  be  used. 

Unfortunately,  no  modelling  methodology  has,  to  our 
knowledge,  been  successfully  developed  for  the  young 
science  of  verification.  The  lack  of  a  methodology  makes 
modelling  even  more  difficult. 

We  must  emphasise  that  by  the  term  “modelling”  we 
do  not  refer  exclusively  to  the  construction  of  the  formal 
security  model,  though  this  construction  is  a  significant 


part  of  the  modelling  process  in  some  verifications  such 
as  the  RAP.  We  must  also  include  the  writing  of  the 
formal  top  level  specification  (TLS)  as  a  part  of  the 
modelling  of  the  system. 

The  modelling  required  for  the  design  verification  of 
the  RAP  is  typical  of  that  needed  in  verification.  We 
can  identify  he  parts  of  the  modelling  process  in  gen¬ 
eral  as  follows: 

(1)  Selection  of  a  methodology  for  the  verification, 
such  as  the  Hierarchical  Development  Methodol¬ 
ogy  (HDM)  [6].  This  selection  has  significant  im¬ 
plications  for  the  verification.  HDM  was  used  for 
the  RAP  verification.  (Other  possible  methodolo¬ 
gies  are  Gypsy  and  Formal  Development  Method¬ 
ology.  Also,  an  Enhanced  HDM  has  recently  been 
released.) 

(2)  Construction  of  a  formal  security  model  derived 
from  a  security  policy.  The  purpose  of  this  model 
is  to  formalize  natural  language  requirements  con¬ 
cerning  security.  As  part  of  the  modelling  process, 
the  functioning  and  adequacy  of  the  model  should 
be  explained.  In  the  case  of  the  RAP  the  formal 
security  model  was  derived  from  an  Air  Force  se¬ 
curity  policy.  Some  explanation  of  the  functioning 
of  the  RAP  accompanied  the  formal  model. 

(3)  Characterization  of  the  design  by  writing  a  formal 
top  level  specification.  The  TLS  was  a  large  and 
significant  part  of  the  modelling  for  the  RAP  veri¬ 
fication. 

(4)  Generation  of  conjectures  during  the  modelling 
process,  which  then  need  to  be  investigated  dur¬ 
ing  the  theorem  proving  process.  In  the  case  of  the 
RAP  verification  we  found  that  it  was  necessary  to 
make  the  exact  nature  of  these  conjectures  as  clear 
as  possible. 

(5)  Justification  of  the  decisions  taken  in  steps  (l)-(4), 
in  order  to  advance  the  (implicit  or  explicit)  claim 
that  the  modelling  is  adequate.  Unfortunately,  it 
is  often  the  case  that  this  aspect  of  the  modelling 
is  not  adequately  carried  out. 

We  have  prepared  some  suggestions  for  improving  the 
modelling  process  in  verification.  These  were  in  part 
prompted  by  our  examination  of  the  modelling  done  for 
the  RAP  verification.  In  looking  at  the  modelling  in  the 
RAP  verification  we  were  particularly  concerned  with 
the  need  for  adequacy,  comprehensiveness,  intelligibil¬ 
ity,  and  simplicity.  These  are  highly  desirable  features 
that  should  be  considered  in  the  modelling  done  in  ver¬ 
ification.  Our  suggestions  are  intended  to  help  verifiers 
make  these  features  a  part  of  their  verifications. 

(1)  Explain  and  carefully  justify  fundamental  decisions 
about  the  modelling. 
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Throughout  a  verification  project,  but  more  espe- 
daily  near  the  beginning,  the  verifiers  should  atten¬ 
tively  think  about  the  modelling  needed  or  being  done. 
Decisions  about  the  modelling  should  be  carefully  doc¬ 
umented  and  justified.  At  the  outset  of  the  RAP  veri¬ 
fication,  certain  modelling  ideas  had  to  be  established, 
i.e.,  decisions  had  to  be  taken  about  how  to  portray  the 
actual  RAP  (the  reality  in  this  case)  as  a  mathemati¬ 
cal  model.  The  RAP  is  a  processor  guarding  the  data 
link  between  the  Network  Control  Center  (NCC)  and 
the  NASA  Communications  Message  Switching  Sys¬ 
tem  (MSS).  Its  purpose  is  to  prevent  uncleared  users 
from  accessing  classified  information  or  facilities  avail¬ 
able  through  the  NCC.  A  security  policy  had  been  pro¬ 
vided  Vy  the  Air  Force  and  the  architecture  of  the  sys¬ 
tem  hardware  had  been  developed.  The  bask  modelling 
problem  was  to  find  mathematical  constructs  that  re¬ 
flected  the  chosen  architecture  of  the  hardware  and  the 
intended  security  of  the  system.  The  verifiers  decided 
to  model  the  operation  of  the  RAP  conceptually  as  se¬ 
quences  of  events  that  passed  over  a  (conceptual)  se¬ 
curity  perimeter.  The  selection  of  a  particular  security 
perimeter  and  a  particular  way  to  portray  the  flow  of 
events  is  a  fundamental  modelling  decision.  Verifiers 
must  not  only  understand  the  nature  of  this  basic  deci¬ 
sion  about  modelling,  but  be  able  to  justify  it  as  well. 

(2)  Give  broad  explanations  of  the  models  and,  if  pos¬ 
sible,  key  information  about  the  process  by  which 
they  were  derived. 

Broad  explanations  of  entire  models  are  extremely 
helpful  to  a  reader  or  reviewer.  Moreover,  information 
about  the  genesis  of  the  models  can  illuminate  the  mod¬ 
els  themselves.  During  the  construction  of  a  formal 
model  various  modelling  decisions  are  made.  These  are 
reflected  in  the  final  constructed  model,  but  often  in 
obscure  ways.  The  key  information  about  the  construc¬ 
tion  of  the  models  ehould  be  preserved  in  an  abbrevi¬ 
ated  form  in  the  documentation. 

In  the  case  of  the  RAP  we  found  that  the  documen¬ 
tation,  though  substantial,  could  have  contained  more 
information  about  the  ideas  behind  the  actual  construc¬ 
tion  of  the  two  main  models,  the  formal  security  model 
and  the  formal  top  level  specification.  To  take  a  sim¬ 
ple  example,  we  found  that  one  very  large  definition  in 
the  formal  security  model  could  be  reduced  to  a  pair  of 
tables.  Once  these  tables  were  constructed,  the  formal 
definition  became  much  easier  to  understand. 

(3)  Choose  a  methodology  that  is  adequate  to  formal¬ 
ise  the  notion*  that  need  to  be  modelled. 

This  choice  is  a  very  difficult  matter.  One  wants  to 
choose  an  adequate  methodology  for  a  verification,  but 
at  present  there  are  only  a  few  from  which  to  choose. 
A  fundamental  modelling  decision  taken  for  the  RAP 


verification  was  to  adopt  the  Hierarchical  Development 
Methodology  (HDM)  [6].  This  decision  had  many  im¬ 
plications  for  the  modelling  process.  Most  notably  it 
implied  the  adoption  of  the  sequential  state  machine 
model,  a  basic  part  of  HDM,  in  the  modelling.  For  this 
general  model  concurrency  is  not  so  easily  taken  into 
account.  Hence,  it  is  at  least  questionable  whether  this 
sequential  model  is  adequate  to  deal  with  the  reality 
of  the  RAP.  Arguments  ought  to  be  given  for  the  (im¬ 
plicit)  claim  that  the  chosen  methodology  is  adequate. 

(4)  Try  to  develop  a  formal  model  that  has  a  direct  and 
clearly  understood  relation  to  the  English  policy 
statement  or  English  requirements  specification. 

The  formal  security  model  was  a  very  significant  part 
of  the  modelling  for  the  RAP  [2],  The  purpose  of  this 
formal  model  was  to  capture  the  Air  Force  security  pol¬ 
icy  in  a  succinct  and  correct  way.  The  model  was  based 
on  event  histories  and  was  written  in  the  specification 
language  SYSPECIAL,  a  variant  of  the  SPECIAL  of 
HDM.  The  heart  of  the  model  consists  of  a  hierarchy  of 
definitions  of  predicates  on  event  histories,  with  a  sin¬ 
gle  predicate  (MBPS.OK)  at  the  top  of  the  hierarchy 
representing  the  desired  security  invariant. 

In  order  to  facilitate  the  construction  of  the  formal 
model  a  shortened  form  of  the  Air  Force  security  pol¬ 
icy  was  developed,  called  the  “derived  security  policy* . 
This  was  undoubtedly  a  great  help  in  constructing  the 
formal  security  model,  in  particular,  in  seeing  how  the 
Air  Force  policy  should  be  related  to  the  model.  The 
derived  security  policy  is  a  terse  English-language  state¬ 
ment  of  the  security  requirements  that  is  closely  related 
to  the  formal  model;  in  many  instances  there  are  direct 
(one-to-one)  correspondences  between  words  of  the  de¬ 
rived  policy  and  functions  or  predicates  of  the  model. 
The  model  would  have  been  even  better  if  k  could  have 
been  a  simpler  formalisation  of  the  policy  with  more 
direct  correspondence  between  policy  and  model.  How¬ 
ever,  formalisation  is  a  very  difficult  art. 

In  general,  formal  models  should  be  made  as  simple 
as  possible  and  the  relation  to  English-language  require¬ 
ments  specifications  should  be  made  as  clear  as  possi¬ 
ble  through  informal  explanations  in  the  documentation 
and  perhaps  through  the  construction  of  derived  policy 
statements.  One  can  see  the  advantages  cf  a  derived 
tersely-worded  security  policy  statement  in  the  case  of 
the  RAP.  Generally  an  English  statement  or  specifica¬ 
tion  should  be  as  simple  as  possible. 

(5)  Definitions  in  a  model  should  have  a  hierarchical 
structure  and  this  structure  should  be  presented 
fully. 

The  definitions  of  the  formal  security  model  for  the 
RAP  were  arranged  in  a  hierarchy.  This  arrangement  is 
certainly  a  good  one.  It  is  one  that  can  be  used  to  good 
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effect  in  modelling  in  verification.  However,  it  is  use¬ 
ful  to  have  as  much  information  as  possible  about  the 
hierarchy.  The  hierarchy  effectively  indicates  a  “flow* 
from  the  most  general  to  the  least  general,  revealing  a 
great  deal  about  the  structure  of  the  model.  The  ver¬ 
ifiers  of  the  RAP  might  have  given  more  information 
about  their  hierarchy.  Their  diagram  of  dependencies 
in  the  hierarchy  was  reduced  to  a  brief  summary  in  the 
documents.  A  general  explanation  of  a  hierarchy  of 
definitions  can  be  very  helpful  as  a  supplement  to  the 
explanations  of  the  individual  definitions  found  in  the 
hierarchy. 

(6)  Use  nonprocedural  forms  of  expression. 

In  our  attempt  to  understand  the  formal  security 
model  for  the  RAP  we  were  led  to  develop  our  own  in¬ 
termediate  mathematical  model  and  explanation.  We 
found  that  it  was  very  helpful  to  remove  the  recursions 
from  the  basic  definitions  in  the  formal  model  and  state 
these  with  the  aid  of  quantifiers  and  logic.  The  formal 
model  as  given  effectively  h»d  a  mix  of  procedural  de¬ 
scription  (the  recursions)  and  strict  iogical  description. 
This  mix  was  not  always  conducive  to  providing  a  direct 
and  clear  exposition  of  the  model. 

It  was  only  by  constructing  our  own  intermediate 
mathematical  model  for  the  given  formal  security  model 
that  we  could  begin  to  sec  the  relation  between  the  En¬ 
glish  security  policy  and  the  given  formal  model.  This 
intermediate  model  allowed  us  eventually  to  decide  that 
for  the  most  part  the  policy  was  correctly  reflected  in 
the  given  formal  model. 

The  modelling  done  in  constructing  the  TLS  for  the 
RAP  [8]  had  some  special  problems,  partly  associated 
with  adoption  of  HDM.  We  found  the  TLS  at  times 
quite  difficult  to  understand.  We  have  a  number  of 
suggestions  for  improver, ent  in  writing  these  kinds  of 
specifications.  In  the  following  we  assume  an  under¬ 
standing  of  the  terminology  of  HDM. 

(7)  Use  homogeneous  data  types,  whenever  possible. 

To  avoid  confusion,  use  homogeneous  data  types.  If 
for  some  reason  the  use  of  homogeneous  data  typeB  is 
impossible,  pending  data  types  should  be  considered. 

(8)  Describe  state  transitions  as  simply  as  possible. 

The  effects  of  O-functions  on  individual  V-functions 
should  be  easily  understood.  Ideally,  the  effects  of  an 
O-function  should  be  of  the  simple  form: 

V  =  P(W), 

where  V ,  W  are  V-functions  and  F  is  some  simple  func¬ 
tion.  The  functionality  of  O-functions  of  this  sort  is 
manifestly  clear  to  a  reader. 

(9)  Provide  an  information  flow  diagram. 


The  flow  of  information  between  V-functions  should 
be  clear.  Ideally,  one  should  be  able  to  represent  the 
flow  induced  by  an  O-function  as  a  directed  graph.  The 
nodes  of  this  graph  correspond  to  V-functions  and  the 
edges  correspond  to  assignment  statements.  Th'  (raph 
provides  a  clear  understanding  of  the  general  architec¬ 
ture  of  the  TLS. 

(10)  Give  adequate  explanations  of  the  relations  among 
the  models. 

This  suggestion  brings  up  the  issue  of  comprehen¬ 
siveness  of  the  models.  One  of  the  goals  of  the  RAP 
verification  was  to  prove  that  the  TLS  satisfied  the  se¬ 
curity  requirement  or  predicate  formalised  in  the  formal 
security  model.  This  formalised  security  requirement  is 
essentially  a  predicate  on  finite  sequences  of  “events*. 
Since  sequences  of  events  do  not  constitute  part  of  the 
state  of  the  TLS  state  machine,  it  is  not  clear  how  to  in¬ 
terpret  th:  assertion  that  the  TLS  satisfies  the  security 
predicate. 

An  interpretation  can  be  made  by  associating  event 
histories  with  certain  sequences  of  O-functions  or  OV- 
functions.  These  sequences  are  the  possible  execution 
sequences  of  the  TLS  state  machine.  The  assertion  that 
the  TLS  satisfies  the  model  then  means  essentially  that 
for  every  execution  sequence,  its  associated  event  his¬ 
tory  satisfies  the  formal  security  predicate.  However, 
this  correspondence  is  not  a  part  of  either  the  formal 
security  model  or  the  TLS.  How  one  associates  an  event 
history  to  an  execution  sequence  is  a  problem  of  mod¬ 
elling.  In  the  case  of  the  RAP,  however,  event  histories 
were  introduced  as  part  of  the  theorem  proving  stage 
in  a  manner  which  seemed  to  suggest  that  one  could 
prove  that  the  association  chosen  was  the  correct  one. 
Nevertheless,  this  association  was  especially  problemat¬ 
ical,  since  crucial  assumptions  about  concurrency  were 
implicitly  made.  In  general,  the  omission  of  the  rela¬ 
tion  between  models  means  that  the  modelling  process 
is  not  as  comprehensive  as  it  should  be. 

3.  THE  THEOREM  PROVING 
PROCESS 

The  second  process  of  formal  verification  is  the  the¬ 
orem  proving  process.  In  this  process  mathematical 
proofs  of  the  conjectures  formulated  during  the  mod¬ 
elling  process  are  constructed  and  analysed.  These 
proofs  serve  two  functions: 

(1)  To  determine  whether  the  conjectures  formulated 
during  the  modelling  process  are  true. 

(2)  To  clarify  the  meaning  of  these  conjectures. 

The  first  function  is  well  understood.  No  doubt  it 
is  the  part  of  formal  verification  that  has  received  the 
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most  attention.  The  second  function  is  often  ignored. 

It  is,  however,  essential  for  identifying  inappropriate  or 
incorrectly  formulated  conjectures,  and  thus  spotting 
apparent  errors  in  the  modelling  process. 

Unlike  the  modelling  process,  the  theorem  proving 
process  is  a  completely  mathematical  endeavor.  Proofs 
of  theorems  are  developed  in  a  well-defined  mathemati¬ 
cal  theory  (created  by  the  modelling  process) ,  in  which 
there  is  no  direct  mention  of  the  real-world  application. 

As  part  of  a  verification,  mathematical  proofs  can 
provide  a  level  of  assurance  for  the  correctness  of  a 
conjecture  that  is  not  obtainable  by  traditional  means 
of  software  testing.  Nevertheless,  mathematical  proofs 
are  not  infallible.  Their  validity  must  be  ultimately 
grounded  in  some  kind  of  critical  process.  In  mathe¬ 
matics,  this  critical  process  occurs  within  the  commu¬ 
nity  of  research  workers. 

Because  proofs  used  in  formal  verification  tend  to  be 
long  and  complicated,  verifiers  usually  try  to  construct 
them  with  the  aid  of  machines  (theorem  proven,  proof 
checkers,  simplifiers,  etc.).  This  approach  is  certainly 
good  and  probably  necessary.  However,  without  care 
it  can  become  an  obstruction  to  the  theorem  proving 
process,  leading  to  results  such  as  the  following: 

(1)  Theorems  are  proved  without  being  clearly  under¬ 
stood. 

(2)  Opaque  calculation  is  given  instead  of  careful 
argument. 

(3)  Proof  analysis  is  given  less  emphasis  than  proof 
construction. 

(4)  Conceptual  simplification  is  overlooked. 

(5)  Errors  in  the  formulation  of  conjectures  are  not 
discovered. 

(6)  The  fallibility  of  proofs  is  forgotten. 

If  verifiers  are  to  construct  good  proofs  with  the  as¬ 
sistance  of  machines,  they  need  to  have  a  clear  under¬ 
standing  of  what  a  verification  proof  should  be.  We  feel 
that  there  are  six  basic  goals  that  a  verification  proof 
should  attempt  to  achieve: 

(1)  A  verification  proof  should  clearly  state  the  theo¬ 
rem  it  purports  to  prove. 

To  any  mathematician  this  goal  is  so  obvious  that 
it  hardly  needs  stating.  Nevertheless,  achieving  this 
goal  is  essential  to  any  good  proof.  A  proof’s  value  is 
diminished  in  proportion  to  the  lack  of  clarity  in  the 
statement  of  the  theorem. 

(2)  A  verification  proof  should  increase  one’s  confi¬ 
dence  in  the  truth  of  the  theorem. 


This  is  clearly  the  major  goal  of  any  proof.  It  is 
important  to  remember  that  proofs  can  never  give  an 
absolute  guarantee  of  correctness. 

(3)  A  verification  proof  should  be  rigorous. 

The  one  thing  that  separates  formal  verification  from 
traditional  ways  of  testing  software  and  computer  sys¬ 
tems  is  that  formal  verification  attempts  to  show  some¬ 
thing  is  correct  with  a  rigorous  proof.  A  rigorous  proof 
strives  to  use  only  well-defined  concepts  and  to  have  no 
loose  ends.  Nothing  is  ignored  or  left  to  chance. 

(4)  A  verification  proof  should  clarify  the  meaning  of 
the  theorem. 

It  is  a  rare  luxury  to  begin  proving  a  conjecture  that 
is  correctly  formulated.  This  is  true  in  general  mathe¬ 
matics  as  well  as  in  formal  verification.  Thus  it  is  very 
desirable  that  the  process  of  proving  a  conjecture  helps 
to  correct  the  statement  of  the  conjecture  itself.  The 
ideal  p.ocess  goes  like  this:  a  (partial)  proof  of  the  con¬ 
jecture  is  constructed,  it  is  analysed,  the  conjecture  is 
modified,  and  the  process  is  begun  again.  The  process 
ends  when  one  is  satisfied  that  a  complete  proof  of  an 
appropriate  and  correct  conjecture  has  been  obtained. 
(Cf.  [5]  for  further  discussion  of  this  “dialectical*  pro¬ 
cess.)  In  order  for  this  process  to  be  successful,  it  is 
necessary  that  verification  proofs  elucidate  the  mean¬ 
ing  of  the  theorems  they  prove.  This  cannot  be  done 
by  proofs  consisting  merely  of  a  long  series  of  opaque 
logical  calculations. 

(5)  A  verification  proof  should  be  maintainable. 

Software  and  computer  systems  need  to  be  modi¬ 
fied  virtually  on  a  continuous  basis.  Hence,  verifica¬ 
tion  proofs  should  be  modified  whenever  the  things  they 
verify  are  modified.  In  other  words,  verification  proofs 
should  be  maintainable  just  as  computer  systems  should 
be  maintainable. 

(6)  A  verification  proof  should  be  machine  checkable. 

Verification  proofs  tend  to  be  long  and  complicated. 
One  cannot  expect  to  check  them  by  hand  without  mak¬ 
ing  mistakes.  It  is  reasonable  to  expect  that  many  cf 
these  mistakes  would  not  occur  when  a  proof  is  machine 
checked.  Although  it  is  desirable  that  a  verification  be 
machine  checkable,  it  is  not  necessary  that  a  verifica¬ 
tion  proof  be  machine  generated.  (Of  course,  it  is  often 
useful  to  construct  parts  of  a  verification  proof  with  the 
aid  of  a  machine.) 

The  state  of  the  art  of  verification  proofs  falls  signif¬ 
icantly  short  of  these  six  goals.  We  believe  that  this  is 
due  in  part  to  an  inadequate  understanding  by  verifiers 
of  what  proofs  should  be  and  what  role  machines  should 
play  in  proof  construction. 
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To  help  illustrate  how  real  verification  proofs  satisfy 
(and  fail  to  satisfy)  the  goals  we  have  stated  above,  we 
shall  briefly  examine  the  verification  proof  for  the  de¬ 
sign  of  the  RAP.  The  RAP  verification  proof  is  a  good 
example  to  consider  because,  although  it  certainly  is 
one  of  the  best  large-scale  verification  proofs  produced 
to  date,  it  exhibits  some  of  the  deficiencies  that  com¬ 
monly  plague  verification  proofs. 

The  principal  theorem  of  the  design  verification  of 
the  RAP  can  be  stated  as  follows: 

THEOREM.  Every  implementation  of  the  Top  Level 
Specification  (TLS)  of  the  RAP  satisfies  the  require¬ 
ments  formulated  in  the  formal  security  model. 

This  theorem  is  only  stated  informally  in  the  RAP  Ver¬ 
ification  Results  Report  (9j  and  its  mathematical  mean¬ 
ing  is  not  explicated  at  all. 

The  proof  of  the  theorem  breaks  up  into  two  parts: 

Part  A.  The  proof  that  the  theorem  holds  if  the  asser¬ 
tions  of  an  Augmented  TLS  (ATLS)  are  invariants  of 
the  ATLS. 

Part  B.  The  proof  that  the  assertions  of  the  ATLS  are 
invariants  of  the  ATLS. 

These  two  parts  are  handled  very  differently.  Part 
A  of  the  proof  is  an  informal  mathematical  argument, 
which  is  given  very  little  attention  relative  to  Pait  B. 
Moreover,  the  argument  is  flawed  because  part  of  the 
modelling  process  (the  construction  of  the  ATLS  from 
the  TLS)  is  mixed  up  with  it. 

Part  B  is  of  a  completely  different  nature  from  Part 
A.  It  is  essentially  a  series  of  36  very  detailed  formal  de¬ 
ductions.  The  formal  deductions  are  not  actually  given 
in  the  Verification  Results  Report  [9|;  instead  logs  are 
given  of  the  theorem  prover  commands  used  to.  con¬ 
struct  the  deductions. 

Part  B  does  a  reasonably  good  job  of  satisfying  the 
goals  of  rigor  (3)  and  machine  checkability  (6) .  Its  suc¬ 
cess  results  from  being  a  formal  proof  constructed  (and 
checked)  with  the  use  of  a  machine.  Since  the  logs 
are  modifiable  and  reusable,  part  B  also  contributes 
to  the  goal  of  maintainability  (6).  The  logs,  however, 
are  opaque.  They  do  not  help  one  to  understand  the 
subtheorems  they  prove,  nor  do  they  communicate  the 
mathematical  meaning  of  the  deductions. 

The  lack  of  perspicuity  in  the  formal  deductions 
means  that  one’s  confidence  in  the  claim  that  the  ATLS 
assertions  are  invariants  of  the  ATLS  is  almost  purely 
a  matter  of  faith  in  the  MUSE  system,  the  theorem 
proving  system  used  to  construct  the  formal  deductions. 
The  MUSE  system  [4]  was  developed  by  Sytek,  Inc.  It 


is  a  competent  and,  in  many  ways,  admirable  theorem 
proving  system.  However,  although  the  MUSE  system 
appears  to  work  correctly,  it  has  not  been  formally  ver¬ 
ified  (like  all  such  systems)  and  it  is  relatively  untested, 
having  thus  far  been  used  on  only  one  large  project.  As 
long  as  the  MUSE  system  itself  is  not  verified,  genuine 
confidence  in  it  can  only  come  after  it  has  been  uned  by 
several  different  parties  on  several  different  projects. 

In  summary,  the  RAP  design  verification  proof  is 
composed  of  an  informal  part  and  a  part  constructed 
with  the  aid  of  a  machine.  The  first  part  received  only 
curso.y  attention.  The  second  part  was  carried  out  in 
gTeat  detail,  but  with  too  much  reliance  on  automated 
reasoning  tools.  Although  the  RAP  verification  proof  is 
successful  in  several  ways,  it  illustrates  some  common 
shortcomings  of  verification  proofs: 

(1)  Insufficient  attention  is  paid  to  the  informal  parts 
of  the  proof. 

(2)  Justification  for  modelling  decisions  is  presented  as 
part  of  the  verification  proof. 

(3)  Formal  deductions  are  not  presented  in  an  under¬ 
standable  form. 

(4)  Too  much  reliance  is  placed  on  unverified  theorem 
proving  tools. 

We  finish  our  discussion  of  the  theorem  proving  pro¬ 
cess  by  giving  five  suggestions  for  constructing  good 
verification  proofs. 

(1)  Use  hierarchical  construction. 

To  be  readable  and  understandable,  long  proofs  must 
be  constructed  in  a  hierarchical  manner.  This  is  em- 
intntly  true  for  verification  proofs,  which  tend  to  be 
oppressively  long  and  full  of  minute  details.  The  com¬ 
ponents  of  a  hierarchical  proof  should  be  subproofs  of 
the  form 

by  the  argument  A,  C  follows  from  Hi . Hn, 

At  the  top  level  C  is  the  conjecture  that  is  proved,  and 
at  the  bottom  level  the  Hj't  are  the  hypotheses  which 
are  being  assumed  or  are  trivially  true. 

The  crucial  parts  of  the  proof  —  the  “idea*  of  the 
proof  —  should  be  in  the  arguments  at  the  top  of  the 
hierarchy,  and  the  tedious  details  of  the  proof  should 
be  at  the  bottom.  One  can  read  a  proof  of  this  form 
part  way  down  and  be  confident  that  the  basic  idea 
of  the  proof  and,  hence,  the  basic  idea  of  the  theorem 
are  correct,  even  though  there  could  be  minor  problems 
with  the  details  of  the  proof  and  the  theorem. 

(2)  Use  modular  construction. 
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Mathematicians  have  been  using  modular  construc¬ 
tion  in  proofs  for  centuries,  and  modular  construction 
is  considered  part  of  good  programming.  It  is  well  un¬ 
derstood  why  modular  construction  is  desirable,  even 
necessary,  in  mathematical  proofs  and  computer  pro¬ 
grams.  To  *  large  extent  the  whole  enterprise  of  formal 
verification  rests  on  one’s  ability  to  develop  methods  of 
modularity.  In  conjunction  with  hierarchical  construc¬ 
tion,  modular  construction  is  an  excellent  way  to  satisfy 
the  goal  of  maintainability. 

By  making  use  of  proof  parts  that  have  been  used 
many  times  (such  as  fundamental  lemmas),  one’s  doubt 
in  a  verification  proof  can  be  directed  to  a  few  spe¬ 
cific  aspects  of  the  proof.  Thu  helps  to  increase  the 
reviewer’s  confidence  in  the  proof  by  allowing  him  to 
concentrate  only  on  what  is  new.  There  is  some  use  of 
modularity  in  the  the  RAP  verification  proof  with  the 
use  of  the  theorem  prover  command  logs. 

(3)  Mentify  all  premises  of  the  proof. 

A  good  proof  of  any  kind  should  clearly  identify  all 
the  premises  used  and  assumed  in  it.  Incorrect  proofs 
often  result  from  the  use  of  hidden  assumptions  that 
are  not  valid.  Following  this  suggestion  should  help 
in  attaining  all  but  the  last  verification  goal.  A  clear 
statement  of  the  theorem  includes  the  premises  that 
are  assumed  (goal  1).  In  a  well-constructed  proof,  the 
aspects  of  the  proof  which  might  be  questionable  are 
concentrated  in  the  premises  of  the  proof  (goal  2).  A 
precise  list  of  premises  is  a  requirement  of  a  rigorous 
proof  (goal  3).  Knowing  the  premises  cf  a  proof  in¬ 
creases  one’s  understanding  of  the  theorem  (goal  4). 
The  premises  of  a  proof  identify  the  conditions  under 
which  the  proof  is  valid  and  can  be  used  again  (goal  5). 

(4)  Use  calculations  carefully. 

Formal  verification  has  been  rejected  by  some  [1]  as  a 
means  of  testing  the  reliability  of  software.  One  of  the 
principal  reasons  for  this  is  that  all  too  often  verification 
proofs  contain  massive  amounts  of  opaque  logical  calcu¬ 
lations.  Calculation  is  certainly  a  very  valuable  aspect 
of  mathematical  reasoning.  However,  if  one  is  going  to 
use  calculations  in  a  fundamental  way  in  a  verification 
proof,  one  needs  assurances  that  the  calculations  are 
performed  correctly.  Until  one  has  these  assurances,  it 
is  very  dangerous  to  accept  the  results  of  calculation 
without  closely  examining  what  was  done. 

Calculations  can  be  incorrect  and,  when  calculations 
are  opaque  (such  as  arithmetic  is  in  a  digital  computer), 
there  is  no  way  of  easily  detecting  errors.  Complicated 
calculations  should  be  used  in  a  verification  proof  only 
when  there  is  a  very  high  assurance  that  they  will  be 
correct.  For  example,  it  is  appropriate  to  use  arithmetic 
calculations  performed  by  a  good  digital  computer  or 
simplifications  performed  by  a  well-tested  and  very  re¬ 
liable  simplifier.  As  prominently  mentioned  by  DeMillo 


et  al.  in  [1),  virtually  all  formal  verifications  to  date 
suffer  in  some  degree  from  excessive  reliance  on  formal 
log<cal  calculation. 

(ii)  Use  an  expressive  high  level  language. 

It  is  clear  that  verifiers  can  greatly  benefit  from  the 
use  of  machines  to  assist  in  .he  development  of  veri¬ 
fication  proofs.  Using  machines  necessitates  working 
with  forma]  languages.  It  is  exceedingly  hard  to  get 
a  machine  to  handle  formal  languages  that  have  the 
expressibility  of  the  informal  languages  used  by  math¬ 
ematicians.  Consequently,  verifiers  have  usually  been 
tempted  into  using  very  simple  formal  languages.  This 
approach  keeps  the  proof  development  at  such  a  low 
level  that  the  verifier  and  reviewer  become  lost  in  a 
heap  of  trivia. 

Relief  can  only  come  with  the  use  of  expressive  high 
level  languages.  Languages  of  this  type  are  difficult  to 
develop  and  difficult  tc  program  a  machine  to  use,  but 
they  allow  human  beings  to  think  naturally  and  to  make 
use  of  the  richness  of  modern  mathematics. 

4.  THE  REVIEW  AND 
ACCEPTANCE  PROCESS 

In  mathematics  the  validation  or  acceptance  of  a  new 
result  is  the  outcome  of  a  complex  interactive  process 
involving  the  author,  the  interested  community,  and  to 
a  lesser  extent  a  technical  reviewer  appointed  by  the  ed¬ 
itor  of  a  journal.  Based  on  our  experience  of  reviewing 
the  RAP,  we  now  discuss  how  the  process  of  validation 
ought  to  occur  in  the  verification  of  design  or  program 
correctness.  We  believe  that  many  useful  analogies  be¬ 
tween  the  validation  processes  in  mathematics  and  in 
verification  can  be  made.  However,  while  these  analo¬ 
gies  exist,  we  still  think  that  the  two  processes  have 
important  differences. 

In  mathematics  (or  in  other  areas  such  as  mathemati¬ 
cal  economics  or  mathematical  physics),  workers  in  each 
area  of  research  try  to  build  on  or  improve  published  re¬ 
sults.  They  are  strongly  motivated  to  understand  these 
results  and  make  sure  that  they  are  correct.  Mathe¬ 
matical  papers  are  normally  structured  in  a  way  that 
p  .mils  understanding  at  many  different  levels.  For 
example,  a  specialist  reader  can  take  a  cursory  look 
at  a  good  mathematical  paper  and  still  get  some  no¬ 
tion  of  the  paper’s  contents.  There  are  also  aesthetic 
reasons  for  reading  mathematical  papers.  Researchers 
read  technical  papers,  not  only  because  they  can  use 
the  results  in  their  own  work,  but  also  because  read¬ 
ing  them  is  a  pleasurable  experience.  Generally,  papers 
that  are  not  well  written  are  not  immediately  received, 
and  the  results  they  claim  take  longer  to  be  accepted 
by  the  community  of  research  workers.  Insuring  that 
their  papers  are  read  is  a  powerful  reason  for  authors 
to  write  clear  as  well  as  interesting  papers. 
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In  contrast  to  the  situation  in  the  other  mathemati¬ 
cal  sciences,  very  few  people  read  verifications  of  large 
programs  or  systems.  Most  of  the  reasons  that  exist  for 
reading  research  papers  do  not  exist  for  reading  verifi¬ 
cation  proofs.  Verification  proofs  are  tedious  and  rarely 
provide  a  basis  for  further  research  in  the  same  way  as 
mathematical  proofs.  Cursory  readings  of  verification 
proofs  provide  absolutely  no  insight.  In  short,  verifica¬ 
tion  proofs  are  written  with  no  intension  of  attracting 
readers.  Generally,  new  software  has  been  accented  ex¬ 
clusively  on  the  claims  of  developers .  In  the  best  of 
circumstances  (as  was  the  case  for  the  RAP)  the  design 
or  code  undergoes  some  sort  of  indep  endent  review  pro¬ 
cess.  Even  in  the  case  of  the  RAP,  the  review  process 
for  the  design  verification  was  not  explicitly  discussed 
in  the  original  verification  plan,  despite  the  fact  that  a 
review  process  for  code  development  was  carefully  es¬ 
tablished. 

As  we  have  argued  above,  the  existence  of  proofs, 
even  automated  ones,  is  in  itself  no  guarantee  of  cor¬ 
rectness.  Proofs  have  to  be  submitted  to  a  thorough  re¬ 
view  process  in  much  the  same  way  as  in  mathematics. 
Sine*  it  is  unlikely  that  verifications  will  attract  inter¬ 
ested  and  critical  readers,  only  a  formal  review  process 
by  appointed  referees  seems  to  be  feasible.  This  re¬ 
view  process  should  be  considered  an  integral  part  of 
the  verification  effort. 

It  is  our  belief  that  the  reviewers  should  be  regarded 
as  the  main  audience  for  a  verification  proof.  If  the 
purpose  of  such  a  proof  is  to  persuade  any  potential 
doubter,  then  at  least  the  reviewers  must  be  convinced 
of  the  correctness  of  the  verification  proof.  A  verifica¬ 
tion  effort  which  fails  to  satisfy  this  condition  cannot 
be  considered  a  proof  in  any  reasonable  sense.  In  order 
to  achieve  these  goals,  the  following  two  conditions  at 
•*t  should  be  met: 

Any  formal  models  used  in  the  verification  must 
be  understandable  without  undue  effort.  Specific 
guidelines  for  clarity  of  specifications  should  ex¬ 
ist  to  aid  specification  writers.  These  guidelines 
should  be  agreed  upon  before  any  formal  models 
are  written. 

(2)  Even  if  automated  tools  are  used,  the  structure  of 
the  formal  proof  must  be  clearly  stated.  Presenting 
the  structure  clearly  makes  the  automated  proof 
more  credible  as  well  as  making  the  verification 
much  more  maintainable. 


5.  SUMMARY 

In  this  paper  we  have  proposed  a  discipline  for  verify¬ 
ing  software.  We  think  that  a  verification  should  consist 
of  three  interactive  processes:  a  modelling  process,  a 
theorem  proving  process,  and  a  review  and  acceptance 


process.  The  modelling  process  should  develop  formal 
mathematical  models  of  all  requirements,  specifications, 
processes,  and  systems  that  are  relevant  to  the  verifica¬ 
tion,  and  should  generate  conjectures  in  the  mathemat¬ 
ical  framework  established  by  the  models.  The  models 
and  conjectures  should  be  clear  and  their  appropriate¬ 
ness  justified.  In  the  theorem  proving  process,  proofs 
of  the  conjectures  generated  during  the  mode’ling  pro¬ 
cess  should  be  constructed  and  analysed.  Unlike  the 
modelling  process,  the  theorem  proving  process  should 
be  a  purely  mathematical  endeavor.  The  review  and 
acceptance  process  should  provide  a  means  of  commu¬ 
nication,  so  that  the  verifiers  can  convince  the  reviewers 
—  and  ultimately  the  customer  —  of  the  adequacy  of 
the  verification. 
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ABSTRACT 

This  paper  describes  the  National  Bureau  of 
Standards  MAC  Validation  System  (MVS)  for 
testing  the  confurmance  of  vendor  devices  to 
Federal  and  commercial  data  authentication 
standards.  Topics  which  are  covered  include 
the  events  which  led  to  the  development  of 
the  MVS,  the  standards  it  validates,  its 
design  philosophy,  the  requirements  it 
places  on  vendors  validating  their  devices, 
its  performance  characteristics,  and  the 
results  of  the  validations  performed  to 
date. 


1  INTRODUCTION 

In  1979  a  group  of  bankers,  vendors, 
financial  network  representatives,  and  a 
member  of  the  National  Bureau  of  standards 
(NBS)  met  for  the  first  time  to  define  and 
write  an  American  National  Standards 
Institute  (ANSI)  standard  for  authenticating 
financial  transactions.  The  impetus  for  the 
standard  came  from  the  bankers  who  were  well 
aware  of  the  large  dollar  amounts  contained 
in  wholesale  electronic  financial 
transactions,  and  the  outdated  methods  used 
to  protect  their  integrity. 

Two  years  later,  the  American  National 
Standard  for  Financial  Institution  Massage 
Authentication  (Wholesale)  was  published  by 
the  American  Bankers  Association  as  ANSI 
X9. 9-1982.  The  standard  made  use  of  the 
Data  Encryption  Standard  (DES)  cryptographic 
algorithm  to  calculate  a  cryptographic 
checksum  or  Message  Authentication  Code 
(MAC) .  The  originator  of  a  message 
calculates  the  MAC  by  encrypting  the  data 
using  the  DES  algorithm  and  a  secret  value 
called  the  key.  The  MAC  is  then  sent  to  the 
recipient  along  with  the  unencrypted 
message.  The  recipient,  who  has  the  correct 
key,  calculates  the  MAC  in  the  same  manner 
as  the  originator  and  compares  it  to  the 
received  MAC.  If  the  comparison  is 
successful,  the  data  is  considered 
authentic.  Otherwise,  an  unauthorized 
modification  is  assumed.  Any  party  trying 
to  modify  the  data  without  knowing  the  key 
would  not  know  how  to  calculate  the 
appropriate  MAC  corresponding  to  the  altered 
data. 
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The  algorithm  used  to  calculate  a  MAC  was 
based  upon  the  DBS  cryptographic  algorithm 
which  was  published  by  NBS  as  a  Federal 
Information  Processing  Standard  in  1977  [6] . 
The  International  Business  Machines 
Corporation  had  made  the  DES  specifications 
available  to  NBS,  and  had  provided 
nondiscriminatory  and  royalty  free  licensing 
for  building  DES  devices.  NBS  established  a 
TBS  validation  program  whereby  twenty-six 
DES  hardware  implementations  have  been 
tested  for  conf oxime  ice  to  the  DES  standard. 
In  addition,  the  specific  method  for  using 
DES  to  calculate  the  MAC  was  also  published 
by  NBS  as  Federal  Information  Processing 
Standards  Publication  (FIPS  PUB)  113  in  1985 
[7}. 

Much  of  the  ANSI  X9.9  standard  deals  with 
extraction  rules  for  determining  what  data 
in  the  transmitted  message  is  to  be 
authenticated  by  the  MAC,  and  editing  rules 
for  providing  transparency  in  applications 
where  slight  modifications  to  the  data  are 
normally  expected.  For  example,  in  manual 
applications  the  received  data  must  be 
reentered  into  the  authentication  device  in 
order  to  be  authenticated.  if  even  one 
character  is  reentered  incorrectly  or  extra 
spaces  are  inserted  between  words,  the 
recalculated  MAC  will  in  all  likelihood  not 
equal  the  received  MAC.  In  these  cases  it 
may  be  desirable  to  minimize  the  chance  of 
human  error  by  authenticating  only  the 
critical  fields  of  the  message,  and  allowing 
extra  spaces  to  be  inserted  between  words 
without  altering  the  MAC. 

Shortly  after  the  publication  of  the  ANSI 
X9.9  standard  it  was  submitted  to  the 
International  Organization  for 
Standardization  (ISO)  as  a  candidate 
international  authentication  standard.  It 
then  became  clear  that  the  ANSI  X9.9 
standard  would  have  to  be  revised  to  conform 
to  the  character  set  requirements  of  the 
International  community.  An  effort  to 
revise  the  standard  was  begun  and  the 
revised  standard  is  expected  to  be  published 
in  1986.  Further  references  to  the  ANSI 
X9.9  standard  in  this  paper  pertain  to  the 
April  7,  1986  version  of  the  revised 
standard  [2], 

In  1984,  the  U.S.  Department  of  Treasury 
wrote  a  policy  directive  requiring  that  the 
department's  Electronic  Funds  Transfer  (EFT) 
messages  be  properly  authenticated  on  all 
new  systems  immediately,  and  on  all  systems 
by  1988  [5).  In  addition,  Treasury  decided 
to  certify  vendor  devices  and  wrote  the 
criteria  that  such  modules  must  meet  [4]. 


NBS  and  the  National  Security  Agency  are  to 
assist  Treas  'ry  with  its  certification.  As 
a  part  of  tuis  cooperative  erfort,  NBS 
agreed  to  develop  a  MAC  Validation  System 
(MVS)  which  would  test  conformance  with  FIPS 
PUB  113  and  ANSI  X9.9.  This  paper  will 
describe  the  MVS  and  the  tests  which  are 
designed  to  validate  conformance  to  FIPS  PUB 
113  and  ANSI  X9.9. 


2  MESSAGE  AUTHENTICATION  STANDARDS 

2.1  Computer  Data  Authentication  (FIPS  PUB 
113) 

In  automated  data  processing  systems  it  is 
often  not  possible  for  humans  to  scan  data 
to  determine  if  it  has  bean  modified. 
Examination  may  be  too  time  consuming  for 
the  vast  quantities  of  data  involved  in 
modern  data  processing  applications,  or  the 
data  may  have  insufficient  redundancy  for 
error  detection.  Even  if  human  scanning 
were  possible,  the  data  could  have  been 
modified  in  such  a  manner  that  it  would  be 
very  difficult  for  the  human  to  detect  the 
modification.  For  example,  "do"  may  have 
been  changed  to  "do  not"  or  "$1,000"  may 
have  been  changed  to  "$10,000".  Without 
additional  information  the  human  scanner 
could  easily  accept  the  altered  data  as 
being  authentic.  These  threats  may  still 
exist  even  when  data  encryption  is  used.  It 
is  therefore  desirable  to  have  an  automated 
means  of  detecting  both  intentional  and 
unintentional  modifications  to  data. 
Ordinary  error  detecting  codes  are  not 
adequate  because,  if  the  algorithm  for 
generating  the  code  is  known,  an  adversary 
can  generate  the  correct  code  after 
modifying  the  data.  Intentional 

modification  is  undetectable  with  such 
codes.  However,  a  cryptographic  MAC  can 
protect  against  both  accidental  and 
intentional,  but  unauthorized,  data 
modification. 


FIPS  PUB  113  defines  an  algorithm  for 
calculating  the  MAC  which  is  consistent  with 
ANSI  X9.9  and  the  Department  of  Treasury's 
Electronic  Funds  and  Securities  Transfer 
Policy.  The  MAC  calculation  is  based  on  the 
DES  cryptographic  algorithm  which  transforms 
64-bit  input  blocks  to  64-bit  output  blocks 
using  a  cryptographic  key  (See  Figure  1) . 
The  data  to  be  authenticated  is  grouped  into 
contiguous  64-bit  blocks:  D1,D2, . . . ,Dn.  If 
the  number  of  data  bits  is  not  a  multiple  of 
64,  then  the  final  input  block  will  be  a 
partial  block  of  data,  left  justified,  with 
zeroes  appended  to  form  a  full  64-bit  block. 
After  the  first  data  block  is  passed  through 
the  DES  algorithm  the  output  is 
exclusive-ORed  to  the  second  data  block  to 
form  the  next  input  to  the  DES.  This 
process  continues  until  the  last  data  block 
is  exclusive-ORed  to  a  DES  output  block  and 
the  result  is  used  as  the  last  input  to  the 
DES.  The  left-most  32-bits  of  the  final  DES 
output  are  taken  as  the  MAC. 

Since  the  outputs  of  each  DES  transformation 
are  chained  to  the  inputs  of  the  next  DES 
transformation,  the  final  MAC  is  a  function 
of  each  bit  of  data  and  the  secret 
cryptographic  key.  When  the  key  is  unknown, 
the  alteration  of  a  single  bit  of  data  will 
cause  an  unpredictable  alteration  of  the 
MAC.  Therefore,  any  intruder  who  intercepts 
authenticated  data  and  attempts  to  make  an 
alteration  does  not  know  what  the 
corresponding  MAC  for  the  altered  data 
should  be. 

The  MAC  algorithm  may  be  used  to  protect  any 
data  (transmitted  or  stored)  which  is 
exposed  to  alteration  between  the  initial 
generation  of  the  MAC  and  the  verification 
of  the  received  MAC.  It  does  not  detect 
errors  which  occur  before  the  MAC  is 
originally  generated. 


Il-Dl 

■ 

-ill 

mm 

I 

mum 

H 

■ 

I 

02  ] 

1 

mm 

1 

|  02 

'  I 

D3  J 

li  -  64-bit  DES  input  block 
Oi  -  64-bit  DES  output  block 
Di  -  64-bit  message  block 
©  -  bitwise  exclusive-OR  operation 

DES  -  Data  Encryption  standard  algorithm 


Figure  1.  The  message  authentication  algorithm 
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2.2  ANSI  X9.9 

The  ANSI  X9.9  standard  defines  a  uniform 
process  to  facilitate  the  protection  of 
wholesale  financial  messages.  The  process 
is  independent  of  the  transmission  media, 
can  be  implemented  in  both  automated  and 
manual  systems,  and  is  usable  by  both  large 
and  small  financial  institutions. 

2.2.1  The  Authentication  Process.  Given  a 
message  to  be  transmitted  from  the 
originator  to  the  recipient,  the 
authentication  process  involves  three  steps. 

(1)  The  originator  of  a  message  computes  a 

message  authentication  ccae  (MAC)  from 
the  contents  (or  selected  contents)  of 
the  message  using  a  secret  key  and  one 
of  five  authentication  options  provided 
by  the  standard.  The  five 

authentication  options,  which  are 
described  in  more  detail  below,  include 
one  option  for  binary  data  and  four 
options  for  ASCII  messages  which 
involve  the  authentication  of  selected 
parts  of  a  message.  Choice  of  the 
authentication  option  and  key  is  the 
responsibility  of  the  originator  and 
the  recipient  and  should  be  specified 
using  procedures  that  are  part  of  a 
bilateral  agreement  between  the 
originator  and  the  recipient. 

(2)  The  originator  transmits  both  the 
unencrypted  message  and  its  MAC  to  the 
recipient  of  the  message. 

(3)  The  recipient  verifies  the  received  MAC 
with  the  message  by  computing  another 
MAC  from  the  contents  (or  selected 
contents)  of  the  received  message 
(excluding  the  MAC  itself,  and  its 
delimiters,  if  any)  using  the  same 
authentication  option  and  key  used  by 
the  originator,  and  comparing  the 
computed  MAC  to  the  MAC  received  with 
the  message. 


The  authentication  process  can  be 
implemented  either  through  software  or 
special  hardware  devices  or  a  combination  of 
the  two.  The  process  provides  verification 
that  the  contents  (or  selected  contents)  of 
a  message  have  not  been  accidentally  or 
deliberately  modified  during  transmission 
between  the  originator  and  the  recipient. 
In  addition,  the  identity  of  the  originator 
of  a  message  is  implicitly  verified  by 
proper  use  of  the  correct  secret  key.  By 
including  the  date  and  a  unique  message 
identifier  in  a  message,  the  authentication 
process  also  provides  verification  of  the 
uniqueness  of  a  message  (i.e.,  that  the 
message  is  not  a  duplicate) .  The  message 
identifier,  which  must  be  authenticated,  is 
a  value  that  does  not  repeat  (typically  a 
sequence  number) ,  such  that  there  is  not 
more  than  one  message  with  the  same  message 
identifier  that  has  the  same  date  and  uses 
the  same  key. 

The  authentication  process  alone  does  not 
guarantee  absolute  security.  The  protection 
provided  applies  only  to  the  parts  of  a 
message  that  are  actually  authenticated. 
Other  parts  of  a  message  are  subject  to 
undetected  alterations.  Written  agreements, 
physical,  personnel,  and  procedural  security 


controls  are  necessary  for  secure 
implementation,  use,  and  protection  of  the 
authentication  process  and  devices.  Keys 
must  be  protected  in  accordance  with  ANSI 
X9 . 17  [ 3  ] . 

2.2.2  The  Authentication  Computation .  The 
MAC  computation  involves  the  application  of 
the  authentication  algorithm  to  the  contents 
of  a  message  based  on  the  authentication 
option  used.  The  algorithm  is  essentially 
identical  to  the  authentication  algorithm 
defined  in  FIPS  PUB  113. 

2.2.3  The  Binary  Authentication  Option. 

The  binary  authentication  option  applies  the 
authentication  algorithm  to  the  entire  body 
of  a  message  represented  as  a  sequence  of 
bits.  The  MAC  is  placed  in  the  message  in  a 
predetermined  location  according  to  a 
bilateral  agreement  between  the  originator 
and  the  recipient. 

The  binary  authentication  option  of  ANSI 
X9.9  provides  compatibility  with  FIPS  PUB 
113  and  is  the  recommended  option  for  the 
authentication  of  bulk  data. 

2.2.4  The  Coded  Character  Set  Authentication 
~Opti~ons .  The  four  coded  character  set 
options " apply  the  authentication  algorithm 
to  either  the  entire  contents  or  selected 
contents  of  ASCII  messages.  All  characters 
of  a  message  must  be  represented  as  8-bit 
ASCII  characters  with  the  leftmost  bit  set 
to  zero  and  the  right-most  seven  bits  set  as 
defined  by  ANSI  X3.4  [1].  If  the  message  is 
represented  by  a  different  character  set 
(e.g. ,  EBCDIC) ,  then  the  message  must  be 
transformed  into  ASCII  before  selecting  the 
contents  of  a  message  and  computing  the  MAC. 


In  all  four  coded  character  set  options,  an 
ASCII  message  contains  fields  (or  message 
elements) ,  which  are  contiguous  strings  of 
characters  designated  for  a  specific 
purpose.  Examples  of  fields  that  may  appear 
in  a  financial  message  include  the 
identities  of  the  credit,  debit,  and 
beneficiary  parties,  the  transaction  value 
and  currency  types,  and  the  identity  of  the 
key  used  for  authentication  (IDA) . 


These  fields  may  or  may  not  appear  in  a 
message,  but  they  must  be  authenticated  if 
they  d«'  appear.  other  fields  that  must 
always  appear  in  a  message  and  must  also  be 
authenticated  include  the  date  of  massage 
origination  (Date)  and  a  message  identifier 
(MID) .  A  MAC  must  also  appear  in  a  message, 
but  is  not  included  in  the  MAC  computation. 
The  formats  of  the  IDA,  Date,  MID,  and  MAC 
fields  are  fixed  by  the  standard,  and  each 
of  these  fields  must  appear  only  once  in  a 
message. 


In  order  to  locate  and  identify  the  fields 
in  a  message  they  must  be  either  implicitly 
or  explicitly  delimited.  A  field  is 
implicitly  delimited  if  its  placement  in  a 
message  Is  either  fixed  or  unambiguously 
specified  by  format  rules.  A  field  is 
explicitly  delimited  if  its  placement  in  a 
message  Is  identified  by  a  complementary 
pair  of  opening  and  closing  explicit 
delimiters  without  any  intervening 
delimiters.  The  standard  establishes  the 
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following  opening  and  closing  explicit 
delimiters: 


Open  Close 

Date:  QD-  -DQ 
IDA:  QK-  -KQ 
MAC:  QM-  -MQ 
MID:  QX-  -XQ 
Text:  QT-  -TQ 


Figure  2  depicts  o  sample  financial  message 
which  uses  these  explicit  delimiters.  The 
use  of  implicit  delimiters  versus  explicit 
delimiters  and  the  formats  of  fields  that 
are  not  fixed  by  the  standard  should  be 
specified  in  the  bilateral  agreement  between 
the  originator  and  the  recipient.  In  all 
cases,  if  a  message  does  not  conform  to 
these  rules,  then  a  syntax  error  must  be 
indicated. 

The  differences  among  the  four  au 
thentication  options  involve  which  parts  of 
a  message  are  actually  authenticated,  i.e., 
which  parts  are  input  to  the  authentication 
algorithm  in  order  to  compute  a  MAC  for  the 
message. 

(1)  The  Entire  Message  with  No  Editing 

Option  simply  applies  tho 

authentication  algorithm  to  the  entire 
message . 

(2)  The  Extracted  Message  Elements  with  No 

Editing  Option  applies  the 

authentication  algorithm  only  to  the 
message  elements  and  their  delimiters. 

The  two  non-editing  options  are  recommended 
for  the  authentication  of  data  whenever  the 
transmission  medium  provides  transparency. 


(3)  The  Entire  Message  with  Editing  Option 
applies  the  authentication  algorithm  to 
the  entire  message,  but  first  edits  the 
contents  according  to  several  editing 
rules  which  modify  carriage  returns  and 
line  feeds,  convert  all  alphabetic 
characters  to  upper-case,  delete  all 
but  certain  acceptable  characters, 
eliminate  leading  spaces,  and  compress 
sequences  of  consecutive  spaces. 

(4)  The  Extracted  Message  Elements  with 

Editing  Option  applies  the 

authentication  algorithm  only  to  the 
message  elements  and  their  delimiters 
after  editing  the  contents  as  above. 

The  editing  options  are  recommended  for  the 
authentication  of  ASCII  data  whenever  the 
transmission  medium  is  not  transparent  to 
the  character  set  being  used  (e.g.,  BAUDOT 
networks.  Telex). 


3  MAC  VALIDATION  SYSTEM 
3 . l  Design  Philosophy 

The  approach  taken  in  the  development  of  the 
MVS  was  based  on  experience  gained  from  the 
KBS  DES  validation  process.  Costs  and  staff 
time  to  administer  the  tests  had  to  be  kept 
to  a  minimum.  It  was  therefore  decided  that 
the  tests  would  ha  automated  and  performed 
on  test  devices  at  remote  locations,  since 
the  tests  were  to  he  automated,  NBS  staff 
would  only  have  to  monitor  the  results  of 
the  tests.  And,  sinoe  the  tests  could  be 
performed  on  remote  devices,  shipping  and 
set-up  expenses  would  be  eliminated. 


TO  YOUR  BANK 
FROM  OUR  BANK 

QD-80  07  14-DQ  /////  1056/  QX-127-XQ 

QT- 

TRNS7R  USD  $1234567,89  FRM  ACCNT  48020-166 
/////  TO  ACCNT  40210-178 

-TQ 

KEEP  ON  QT  EXPECT  VISIT  ON  FRIDAY  OF 
NEW  DIV  VP  ON  PROJECT  QT-QWERT-TQ  BE 

Careful 

REGARDS 

QUIRTO 

QK- 1 3  5  7  BANKATOBANKB-KQ 
QM-D21F  3879-MQ 


Figure  2.  sample  financial  message 
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VENDOR  LOCATION 


NBS 


DUT  “  Device  Under  Teat 

DPC  «  Device  Protocol  Converter 

PC  =  Parsonal  Computer 

RBBS  “  Remote  Bulletin  Board  System 

MVS  «  MAC  Validation  System 


Figure  3.  Basic  configuration 


When  initial  DES  validations  were  performed, 
much  time  was  spent  interfacing  vendor 
devices  to  the  NBS  test  device.  In  the  case 
of  the  MVS,  it  was  decided  to  specify  the 
MVS  interface  and  require  that  the  vendor 
match  the  device  to  the  interface.  In  most 
cases  this  can  he  accomplished  with  a 
PC-based  device  protocol  converter  (DPC) 
because  the  interface  is  represented  as 
specific  message  protocols,  including 
message  flow  and  format,  between  the  MVS  and 
the  device  (see  Figure  3) . 

The  intent  of  the  validation  process  is  to 
provide  a  rigorous  conformance  test  which 
can  be  performed  at  a  modest  cost.  NBS  does 
not  try  to  prevent  a  dishonest  vendor  from 
purchasing  a  validated  device  and  remotely 
validating  the  device  as  the  vendor's  own 
product.  However,  customers  who  wish  to 
protect  theMselves  against  a  dishonest 
vendor  could  require  that  the  vendor 
revalidate  the  device  in  the  customer's 
presence. 


3.2  Basic  Configuration 

The  MVS  is  implemented  on  a  personal 
computer  (PC)  equipped  with  a  1200  baud 
modem  and  a  DES  encryption  board.  A  public 
domain  Remote  Bulletin  Board  System  (RBBS) 
is  used  to  provide  controlled  access  to  the 
MVS  by  the  vendor  and  the  vendor's  message 
authentication  device,  the  Device  Under  Test 
(DUT)  (see  Figure  3) .  In  addition,  the  RBBS 
features  could  be  used  to  provide  the  user 


with  information  on  how  to  use  the  system 
and  with  a  list  of  currently  validated 
products.  The  MVS  is  accessed  using  the 
"WINDOW"  command  of  the  RBBS  which  allows 
programs  to  be  run  which  are  external  to  the 
RBBS  program.  When  the  MVS  is  activated, 
the  user's  identity  and  password  are 
requested  followed  by  a  menu  of  options  for 
debugging,  validating  and  status  checking. 
Test  activity  is  logged  in  order  to  resolve 
any  discrepancies  in  expected  test  results. 


3.3  Validation  Protocol 

The  MVS  permits  the  vendor  to  both  r'ebug  and 
validate  a  device  for  any  of  the  five  ANSI 
X9.9  authentication  options  (and  FIPS  PUB 
113)  using  similar  protocols  (sea  Figure  4) . 
Details  of  these  protocols,  including  the 
specific  message  flow  and  formats,  are  given 
in  the  NBS  Message  Authentication  Device 
Validation  Requirements  [11].  The  debug 
capability  permits  the  vendor  to  test  the 
MVS  in  the  same  manner  that  the  MVS  tests 
the  DUT  during  validation.  This  capability 
is  provided  for  the  vendor's  benefit  and  is 
not  required  for  validation. 

Durirg  validation  the  MVS  attempts  to 
validate  the  DUT  for  each  selected  option  by 
sending  requests  to  which  the  DUT  must 
respond.  As  depicted  in  Figure  5, 
validation  message  flow  begins  with  the  DUT 
sending  a  READY  message  to  the  MVS  to 
indicate  that  the  DUT  is  ready  to  proceed 


Options 


Debug  Options 


Validate  Options 


Binary 

Suboption 


Coded  Character 
Set  Suboptions 


Binary 

Suboption 


Coded  Character 
Set  Suboptions 


Figure  4.  MVS  Debug  and  Validate  Options 
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with  tasting.  Validation  tasting  for  the 
Binary  Option  will  begin  at  this  point; 
vheraas,  for  aach  of  tha  Coded  Character  Sat 
Option?,  a  sequence  of  ten  keys  and 
associated  identities  must  first  be  sent  by 
the  HVS,  followed  by  a  COKTINum  saitsage 
which  ia  sent  by  the  OUT. 

a  series  of  validation  tests  follows,  aach 
test  consisting  of  a  request  sassage,  a 
response  sassage  and  a  confirm  sassage.  A 
request  sassage  is  sent  by  tha  MVS  to 
requast  that  tha  OUT  either  compute  a  MAC 
from  a  sassage,  or  verify  a  .MAC  in  a 
sassage.  A  request  aessage  for  the  Binary 
Option  consists  of  a  key  and  data  pair.  The 
data  say  or  say  not  contain  a  MAC.  The 
request  massage  for  s  Coded  Character  Set 
Option  contains  a  sequence  of  ASCII 
characters  formatted  according  to  the  Coded 
Character  Set  Rules  described  in  ANSI  X9.9. 
The  response  sassage  is  sent  by  the  DUT  and 
may  have  several  forms,  depending  on  the 
exact  nature  of  the  request  sassage.  It  say 
contain  the  computed  MAC  of  the  data 
contained  in  the  request,  an  indication  of 
whether  or  not  the  MAC  contained  in  tha  data 
is  correct,  or  it  say  indicate  that  the  data 
had  a  syntax  error.  The  confirs  sassage  is 
sent  by  the  MVS  to  indicate  whether  or  not 
the  OCT  returned  the  correct  response.  Upon 
completion  of  a  validation  option,  the  MVS 
sends  a  completion  message  to  indicate  tha 


final  status  of  the  testing  for  that  option. 


During  validation  tasting  the  MVS  maintains 
a  ratast  count.  Whenever  the  DUT  provides 
an  incorrect  response  to  a  test,  the  HVS 
automatically  repeats  the  ease  request  in 
the  next  test.  If  the  DUT  provides  the 
correct  response  within  three  tests  using 
ths  seme  request,  the  retest  count  Is 
incrsssnted  by  one.  If,  however,  the  DUT 
provides  an  incorrect  response  for  three 
teste  using  the  sase  request,  the  retest 
count  is  incremented  by  a  large  value  to 
indicate  a  test  failure.  Testing  continues 
in  either  case.  At  the  conclusion  of 
tasting,  the  retest  count  is  evaluated  to 
determine  the  validation  status.  If  the 
retest  count  is  greater  than  5  (because  of  a 
complete  failure  an  a  test  or  the  retest  of 
sore  than  5  different  requests) ,  the 
cospletion  message  indicates  that  the 
validation  option  was  not  conpleted 
successfully.  Otherwise,  the  cospletion 
aessage  indicates  that  the  option  was 
successfully  completed. 

Tha  DUT  say  receive  validation  credit  for 
any  of  the  five  options.  However, 
successful  validation  of  the  Binary  option 
is  a  prerequisite  for  successful  validation 
of  any  of  tha  four  Cod(  1  Character  Set 
Options. 


< 


< 


< 


< 


< 


Ready  Message 


Key  Messages* 
Continue  Message* 


Request  Message 
Response  Message 
Confirm  Message 


Request  Message 
Response  Message 
Confirm  Message 


Completion  sassage 


> 


> 


> 


MVS 


> 


DUT  -  Device  Under  Test 

DPC  «■  Dovica  Protocol  Converter 

MVS  -  MAC  Validation  System 

*  The  key  and  continue  messages  are  used 
in  the  coded  Character  set  options  only 


Figure  5.  Message  flow  for  the  validate  suboptions 
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3.4  Validation  Tests 

3.4.1  Binary  Option  Testa.  The  following 

types  of  tests  are  performed  in  the  Binary 

Validate  Suboption: 

(1)  235  selected  key  and  data  combinations 
(without  a  MAC)  which  are  related  to 
those  given  in  Appendix  3  of  KBS 
Special  Publication  500-20  [8] ,  except 
that  the  data  consists  of  the  given 
data  with  one  to  eight  hexadecimal 
ASCII  ones  appended.  These  tests  are 
used  to  check  for  the  proper 
functioning  of  the  DES  algorithm. 

(2)  192  selected  key  and  data  combinations 
(without  a  MAC)  which  are  related  to 
thoso  generated  by  the  DES  Maintenance 
Test  as  specified  in  KBS  Special 
Publication  500-61  [9],  except  that  the 
data  consists  of  the  generated  data 
with  one  to  eight  hexadecimal  ASCII 
ones  appended.  The  DES  Maintenance 
Test  creates  a  cycling  process 
consisting  of  a  maximum  of  192 
encryption  and  decryption  operations 
intermixed  in  such  a  way  as  to  test  all 
aspects  of  the  DES  algorithm.  These 
encryption  and  decryption  operations 
are  used  here  as  an  additional  check 
for  the  proper  functioning  of  the  DES 
algorithm. 

(3)  At  least  100  key  and  data  combinations 

(without  a  MAC)  which  are  randomly 
generated.  Some  of  the  combinations 
consist  of  data  whose  length  is  not  a 
multiple  of  64  bits  so  that  the  DUT  has 
to  correctly  pad  the  data  in  the  MAC 
computation.  These  teste  are  used  to 
check  the  ability  of  the  DUT  to 

correctly  compute  a  MAC. 

(4)  At  least  100  key  and  data  combinations 

(with  a  MAC)  which  are  randomly 
generated.  Approximately  half  of  the 
MAC'S  are  randomly  chosen  to  be 
incorrect.  These  tests  are  used  to 
check  the  ability  of  the  DUT  to 

correctly  compute  a  MAC  and  compare  it 
to  a  given  ItAC. 


3.4.1  Coded  Character  Set  Options  Tests. 

For  all  of  the  Coded  Character  Set  Validate 

Suboptions  the  following  are  tested: 

(1)  The  ability  of  the  DUT  to  compute  a 
MAC.  The  example  message  given  in 
Appendix  u  ’  ansi  X9.9  is  used  along 
with  several  other  test  messages. 
Messages  that  are  modified  by  deleting, 
inserting,  modifying,  and  transposing 
characters  are  used  to  check  that  the 
DUT  can  detect  such  modifications. 
Messages  of  varying  lengths,  and  hence, 
requiring  padding  are  used,  as  well  as 
messages  which  include  the  antire  ASCII 
character  set  both  with  and  without  the 
parity  bits  being  set. 

(2)  The  ability  of  the  DUT  to  compute  a  MAC 
and  compare  it  with  a  received  MAC. 
The  same  messages  used  above  are  used 
here,  except  that  the  messages  should 
contain  a  MAC.  Approximately  one  half 
of  the  massages  contain  an  incorrect 
MAC. 


(3)  The  ability  of  the  DUT  to  process 

explicit  delimiters.  The  messages  wed 
contain  incomplete  explicit  delimiters, 
lowercase  explicit  delimiters, 

unexpected  opening  or  closing  explicit 
delimiters,  missing  closing  explicit 
delimiters,  mismatched  opening  and 
closing  explicit  delimiters,  and  pairs 
of  explicit  delimiters  that  are 
transposed. 

(4)  The  ability  of  the  DUT  to  process 

massage  element  formats.  Messages 
containing  the  message  elements  with 
fixed  message  element  formats  (i.e., 
Date,  IDA,  MAC,  and  MID)  are  used. 
Both  correct  and  incorrect  message 
element  formats  are  checked. 

(5)  The  ability  of  the  DUT  to  process 

messages  which  are  missing  required 
message  elements  or  contain  multiple 
occurrences  of  message  elements  which 
should  appear  only  once. 

(6)  The  ability  of  the  DUT  to  apply  the 
message  element  extraction  rulas  for 
the  extracted  message  element  options 
(editing  and  non-editing) . 

(7)  The  ability  ot  the  DUT  to  apply  the 
editing  rules  in  the  proper  order  for 
the  editing  options  (entire  message  and 
extracted  meosage  elements) .  Messages 
which  exercise  all  of  the  editing  rules 
are  used. 


3 . 5  Validation  Procedures 

The  KBS  Massage  Authentication  Device 
Validation  Procedures  [10]  outline  the  steps 
that  must  be  followed  by  a  vendor  wishing  to 
use  the  MVS  to  validate  their  message 
authentication  device  as  part  of  the 
Treasury  certification  process.  The 
procedure  consists  of  six  steps,  including 
the  application  to  Treasury,  validation  by 
the  MVS,  and  final  certification  by 
Treasury . 


4  MVS  IMPLEMENTATION  ISSUES 

4.1  Performance  Issues 

Since  validation  will  be  performed  from 
remote  locations  using  dialup  access,  the 
telephone  lines  may  introduce  errors  if  a 
poor  connection  ia  obtained.  The  protocol 
has  been  designed  to  allow  for  recovery  from 
communication  garbles  bv  repeating  messages 
upon  request.  In  addition,  the  length  of 
time  required  to  conduct  testing  was  chosen 
to  be  short  enough  that  a  vendor  will  have  a 
high  probability  of  passing  a  test  if  the 
vendor's  device  has  been  correctly 
implemented,  but  lengthy  enough  to  test  the 
vendor's  device  for  conformance  to  the 
implementation  requirements.  Using  a  1200 
baud  commmunicatlons  line,  the  test  set  for 
the  Binary  Option,  which  consists  of  627 
messages,  requires  about  21  minutes  to 
validate,  whereas  the  test  set  for  the  Coded 
Character  Set  Options,  which  consists  of  455 
massages,  requires  about  13  1/2  minutes. 
Final  validation  will,  therefore,  be 
completed  in  about  75  minutes  if  all  of  the 
options  are  tested. 
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guarantee  that  a  DUT  would  implement 
such  a  check  in  the  same  fashion  as  the 
MVS.  Therefore,  checking  the  values  of 
the  date  field  was  not  Included  in  the 
MVS.  It  was  decided  that  this  type  of 
checking  must  be  performed  outside  of 
the  authentication  process. 


4.3  Successful  Validations 


4.2  Problems  and  Issues  Encountered  and 

Solved 

A  number  of  problems  were  encountered  during 

the  implementation  of  the  MVS.  Some  of  them 

along  with  their  solutions  were: 

(1)  During  the  testing  of  the  Coded 
Character  Set  Options,  two  different 
responses  were  required.  Sometimes  it 
was  desired  that  the  DUT  compute  a  MAC, 
compare  it  to  a  received  MAC,  and 
respond  with  the  result  of  the 
comparison.  At  other  times,  it  was 
desired  that  the  DUT  compute  a  MAC  and 
respond  with  the  computed  MAC.  As  a 
result,  two  types  of  request  messages 
are  sent  by  the  MVS  for  the  Coded 
Character  Set  Options. 

(2)  For  the  Binary  option,  it  was 
considered  desirable  to  include  key  and 
data  combinations  that  would  test  all 
functional  aspects  of  the  DES  algorithm 
(e.g.,  permutations  and  S-boxes) .  The 
initial  data  was  taken  from  NBS  Special 
Publication  500-20  [8).  However,  it 
was  found  during  the  first  official 
validation  that  many  of  the  tests  were 
failing  because  the  test  set  included 
self-dual  (weak)  keys  and  the  DUT 
rejected  these  keys.  It  was  therefore 
decided  to  modify  the  tests  so  as  to 
not  include  the  four  self-dual  keys. 

(3)  For  the  testing  of  the  Coded  Character 
Set  Options,  ANSI  X9.9  does  not  specify 
that  the  IDA  (key  identity)  field  is 
required.  In  actual  operation  the 
users  would  use  a  key  that  was 
previously  agreed  upon  (a  "default" 
key) ,  It  was  decided  to  use  the  first 
key  of  the  ten  keys  sent  at  the 
beginning  of  testing  as  the  "default" 
key.  The  question  was  also  raised  of 
how  to  handle,  the  the  case  where  the 
IDA  delimiters  are  present,  but  the 
field  is  empty,  or  NULL.  It  was 
decided  to  handle  this  as  a  key  whose 
identity  was  NULL  rather  than  using  the 
"default"  key. 

(4)  There  is  a  problem  inherent  in  testing 
several  options.  How  do  you  prevent  a 
vendor  from  modifying  their  device 
between  the  successful  validation  of 
one  option  and  the  testing  of  another 
option?  The  modification  could  affect 
the  results  of  the  previously 
successful  validation  if  it  were  to  be 
rerun.  Therefore,  a  final  validation 
step  was  included  which  tests  each  of 
the  options  in  sequence  as  selected  by 
the  vendor.  Credit  for  the  validation 
of  the  vendor's  device  is  nqt  awarded 
until  this  final  validation  process  is 
performed. 

(5)  For  t.ne  testing  of  the  Coded  character 
Set  options,  ANSI  X9.9  does  not  specify 
any  bounds  on  the  value  of  tha  date 
field.  It  does  not  specify  whether  a 
year  of  01  refers  to  1901  or  200x,  nor 
whether  to  check  tho  number  of  days  in 
February,  which  varies  depending  on 
leap  years.  While  tho  addition  of  such 
checks  on  tha  date  might,  be  reasonaola 
and  desirable,  without  a  standard  way 
of  doing  so  there  is  no  way  to 


During  May  1986,  the  Personal  Computer 
Security  Module  (PCSM) ,  a  product  of 
Analytics  Communications  Systems,  Inc., 
successfully  completed  the  NBS  tests  for  the 
Binary  Option  of  ANSI  X9.9.  Other  vendors 
and  organi rations  have  expressed  an  interest 
in  and  the  intent  to  validate  authentication 
devices  and  softvaro  using  the  MVS. 


5  FUTURE  EFFORTS 

NBS  plans  to  continue  to  support  the  MVS  as 
a  part  of  the  Treasury  certification 
process.  In  addition,  NBS  will  support  the 
MVS  for  other  Government  and  commercial 
applications.  It  is  expected  that  6-7 
message  authentication  devices  will  be 
validated  within  the  next  year. 

NBS  is  beginning  to  develop  the  Key 
Management  Validation  System  (KMVS)  which 
will  permit  remote  conformance  testing  of 
the  automated  key-distribution  protocols 
specified  in  ANSI  X9.17,  Financial 
Institution  Key  Management  (Wholesale) .  The 
KMVS  will  be  similar  to  the  MVS,  but  more 
complicated  duo  to  the  complexity  of  the 
standard,  especially  the  wide  variety  of 
options  allowed  by  the  standard. 


6  CONCLUSION 

NBS  has  developed  the  MAC  Validation  System 
which  is  incorporated  into  a  bulletin  board 
system  to  permit  automated  remote 
conformance  testing.  It  was  necessary  to 
define  protocols  interfacing  the  MVS  and  DUT 
in  order  to  allow  testing  of  different 
vendor  devices.  This  approach  reduces  the 
amount  of  manual  intervention  and  overall 
costs  while  providing  a  rigorous  conformance 
test  for  the  FIPS  PUB  113  and  ANSI  X9.9 
standards . 
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ABSTRACT 

This  paper  describes  research  recently  started  to 
discover  if  existing  software  analysis  tools  can  be 
used  to  find  classes  of  security  errors  in  existing  mili¬ 
tary  software.  It  is  assumed  that  the  requirements 
and  specifications  for  the  software  are  not  available, 
and  that  only  the  source  code  is  used  in  the  analysis. 

Introduction 

The  current  arsenal  of  security  analysis  techniques 
relics  on  the  fact  that  the  program  being  analyzed  is  either 
under  development  or  has  recently  been  developed,  and 
therefore,  that  the  requirements  and  the  specifications  are 
available  to  the  security  analyst.  These  techniques  are  of 
little  use  in  analyzing  existing  software  for  which  such 
documentation  is  unavailable.  Without  the  requirements 
and  specifications  available  to  the  security  analyst, 
automated  analysis  tools  that  can  scan  the  source  code  for 
security  flaws  would  be  a  useful  addition  to  the  security 
arsenal.  The  aim  of  this  research  is  to  use  existing  software 
analysis  tools  (e.g.  data  flow  analyzers,  flowchart  genera¬ 
tors,  etc)  to  see  if  they  can  detect  certain  classes  of  security 
errors  in  source  code. 

Many  security  flaws  in  software  are  the  result  of  poor 
programming  practices  or  software  bugs  inadvertently 
Introduced  by  the  programmer.  Put  another  way,  many 
software  errors  can  be  exploited  as  security  flaws.  By  con¬ 
centrating  on  these  software  errors,  an  analyst  can  make  a 
classification  relating  the  errors  to  associated  security  flaws. 
These  security  flaws  can  then  be  found  by  using  the 
appropriate  software  analysis  tool.  Although  this  technique 
will  not  identify  all  security  flaws  in  a  program,  it  will  iden¬ 
tify  many  flaws  that  are  associated  with  software  errors. 

The  goal  of  this  research  is  to  identify  classes  of  secu¬ 
rity  flaws  that  can  and  cannot  be  revealed  through  the 
application  of  software  analysis  tools.  Both  static  and 
dynamic  analysis  techniques  will  be  applied  to  programs 
seeded  with  security  flaws  to  identify  these  classes.  This 
paper  reports  preliminary  results  on  tools  for  static  analysis 
and  how  they  may  help  analysts  locate  security  flaws. 


Analysis  Techniques 

Software  analysis  tools  can  generally  be  broken  into 
two  classes:  static  analysis  tools  and  dynamic  analysis  tools. 
Static  analysis  tools  examine  the  source  code  without  exe¬ 
cuting  it;  dynamic  analysis  tools  analyze  the  complied  code 
by  instrumenting  and  executing  it.  In  the  first  phase  of  this 
study,  static  analysis  tools  will  be  examined  and  in  the  next 
phase,  dynamic  analysis  tools  will  be  used. 

Dynamic  analysis  is  expected  to  yield  more  information 
about  the  security  characteristics  of  the  software,  but  at  a 
greater  cost  both  in  algorithmic  complexity  and  labor  than 
static  analysis.  Static  analysis  techniques  are  more  easily 
automated  and,  in  general,  the  results  need  less  human 
interpretation. 

Static  Analysis  Techniques 

Static  analysis  tools  can  be  classified  by  function:  code 
analysis,  program  structure  analysis,  program  module  inter¬ 
face  analysis,  and  event  scqut-nco  analysis  [20]. 

Code  analysis  is  a  syntactic  check  of  the  source  code; 
it  is  an  extension  of  the  compilation  process.  Several  com¬ 
mon  programming  errors  can  be  found  with  this  method, 
including  improper  use  of  variables  (e.g.  variable  used  but 
not  initialized,  variable  initialized  but  not  used)  and  error 
prone  constructions.  Although  many  newer  compilers  now 
check  for  these  errors,  older  compilers  do  not,  and  so  this 
capability  is  important  in  the  analysis  of  existing  software. 
Code  analysis  may  also  be  used  to  extract  information  that 
can  be  used  later  for  checking  the  relationships  between 
modules  of  the  program,  i.e.  parameters,  global  variables, 
etc. 

Structure  analysis  can  be  used  to  construct  graphs  of 
the  program  which  can  then  be  checked  for  flaws  such  as 
improper  loop  nestings,  unreferenced  labels,  and  unreach¬ 
able  statements.  Termination  checks  can  be  performed  in 
cases  where  the  loop  controlling  variables  are  data- 
insensitive. 

Whereas  the  previous  two  types  of  analysis  affect  sin¬ 
gle  procedures  or  subroutines,  module  interface  analysis 
looks  for  semantic  defects  across  their  boundaries.  The  pur- 
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pose  of  this  analysis  is  to  detect  'nconsistencies  in  the 
declaration  and  use  of  global  data  structures  and  parame¬ 
ters.  For  example,  the  types  and  number  of  parameters 
should  be  consistent. 

With  event  sequence  analysis,  specified  events  are 
examined  to  assure  that  they  are  in  the  proper  sequence. 
For  example,  in  writing  to  a  file,  the  file  must  be  opened, 
written  to  and  then  closed.  Event  sequence  analysis  appears 
to  be  the  most  effective  approach  to  finding  security  related 
errors  as  will  be  discussed  later. 

Now  that  the  various  functions  of  static  analysis  tools 
have  been  examined,  specific  types  of  analyses  will  be 
examined,  with  reference  to  specific  tools.  Most  tools  com¬ 
bine  several  of  the  above  functions. 

Complexity  Analysis 

When  a  security  analyst  begins  to  analyze  a  large  sys¬ 
tem,  he  needs  some  method  of  deciding  where  to  begin. 
Most  systems  are  too  large  to  desk  check  in  their  entirety. 
One  method  is  to  identify  the  most  complex  modules,  and 
use  those  modules  as  a  starting  point  for  further  analysis. 

One  recently  developed  static  analysis  tool  is  based  on 
software  complexity  metrics.  Developed  by  the  U.S.  Army 
Electronic  Proving  Grounds,  the  Fortran  Complexity 
Analysis  Program  (FCAP)  [0]  calculates  McCabe’s  cyclic 
complexity  [15]  and  the  components  needed  to  calculate 
Halstead’s  various  metrics  [lOj. 

The  use  this  kind  of  tool  in  locating  security  flaws  is 
indirect.  As  noted  by  C.  R.  Attanasio  in  an  operating  sys¬ 
tem  penetration  report,  “...relative  design  simplicity  was 
found  to  be  the  source  of  greatest  protection  against  pene¬ 
tration  efforts.  ...simplicity  enhances  the  probability  of 
obtaining  security.”  [2]  A  security  analyst  can  use  a  tool 
such  as  FCAP  to  find  the  most  complex  modules  in  the 
software  and  use  that  as  the  basis  for  a  more  complete  desk 
check. 

McCabe’s  metric  measures  complexity  based  on  how 
many  control  paths  exist  in  a  single  module.  If  a  control 
graph  of  a  module  written  in  a  high  level  language  is 
created,  McCabe’s  metric  would  be  the  number  of  faces  of 
the  graph  (regions  in  a  planar  graph)  plus  one.  According  to 
McCabe,  no  module  should  have  a  complexity  greater  than 
ten.  FCAP  will  identify  all  modules  which  have  a  McCabe 
complexity  greater  than  a  user-defined  value.  All  such 
identified  modules  would  then  be  subjected  to  a  more 
rigorous  desk  check  or  further  static  analysis. 

Halstead’s  metric  is  an  estimation  of  the  length  of  a 
module  or  program,  and  is  calculated  by  formula  using  a 
count  of  the  number  of  distinct  and  total  operands  and 
operators.  Although  various  tools  will  calculate  Halstead's 
length  metric,  this  metric  does  not  seem  to  have  the  same 
applicability  to  locating  security  flaws  in  software  as 
McCabe's. 

Pattern- directed  analysis 

Probably  the  most  useful  technique  in  security  analysis 
is  pattern-directed  analysis.  In  this  technique,  a  suspected 
security  flaw  is  characterized  as  one  or  more  statements  in 
sequence,  but  not  necessarily  adjacent.  The  sequence  is 
then  searched  for,  and  if  found,  is  subjected  to  a  desk 
check. 

What  patterns  are  suspicious?  “From  the  softwo.re 
point  of  view,  both  the  operating  system  and  each  applica¬ 


tion  program  bear  responsibility  for  maintaining  data  secu¬ 
rity.  It  is,  however,  the  operating  system  that  controls, 
assigns,  allocates,  and  supervises  all  resources  within  the 
computer  system.”  [1]  Various  resources  and  data  are  acces¬ 
sible  to  an  application  program  only  after  “appropriate 
dialogue  (i.e.  system  calls)  with  the  operating  system. 
...should  the  operating  system  be  tricked.. .or  compromised 
by  an  application  program,  the  confidentiality  of  informa¬ 
tion  may  be  violated."  [l]  Therefore,  one  area  of  interest 
might  be  to  examine  tho  application  program’s  use  of  sys¬ 
tem  calls,  or  any  calls  outside  of  the  software  being  exam¬ 
ined. 

Also  suspect  are  routines  that  attempt  core  dumps, 
routines  that  do  not  clear  memory  buffers  or  data  areas 
after  use,  direct  addressing  of  memory,  non-documented 
instructions  or  instructions  with  known,  undesirable  side- 
effects,  etc.  For  example,  all  constants  other  than  zero  and 
one  in  a  program  should  be  regarded  as  suspect  since  if  not 
used  in  unit  conversions,  constants  could  Indicate  the  use  of 
direct  memory  access. 

The  most  well-known  tools  of  this  class  are  the  RISOS 
(Research  in  Secured  Operating  Systems)  tools  [19].  Several 
of  the  tools  in  RISOS  will  search  an  assembly  language  pro¬ 
gram  for  selected  patterns  that  might  indicate  security 
flaws.  The  security  analyst  can  enter  a  suspected  pattern 
and  either  have  the  number  of  occurrences  of  that  pattern 
reported,  or  have  the  location  of  the  occurrences  flagged. 
The  analyst  can  also  have  the  lack  of  some  pattern  flagged. 

The  RISOS  tools  were  specifically  designed  for  assem¬ 
bly  language  analysis.  However,  the  simple  pattern- 
directed  search  of  the  RISOS  tools  is  not  sufficient  for 
high-level  languages.  Due  to  the  control  structure  of  high- 
order  languages,  two  patterns  may  not  appear  to  follow 
each  other  in  a  simple  top-down  search.  For  high-order 
languages,  the  control  structure  must  be  taken  into 
account.  Control  flow  analysis  along  with  data  flow  analysis 
is  a  technique  that  allows  more  robust  type  of  pattern- 
directed  search. 

Control  Flow  Analysis 

Control  flow  analysis  examines  the  control  structure  of 
high-level  programs.  This  technique  allows  checking  pro¬ 
grams  for  improper  subprogram  usage  and  violations  of 
control  flow  standards. 

By  itself,  this  technique  allows  a  limited  number  of 
flaws  to  be  detected.  In  particular,  unexceutable  (unreach¬ 
able)  sections  of  code  can  be  identify  d,  and  a  call  graph  of 
the  program  and  flow  graph  of  each  module  can  be  created 
and  manually  inspected.  Additionally,  it  is  possible  to  find 
violations  of  a  specified  standard,  e.g.  backward  jumps  out 
of  a  control  structure  are  not  allowed. 

The  call  graph  indicates  the  structure  of  the  program 
with  respect  to  subroutines  and  possible  errors.  The  pres¬ 
ence  of  cycles  in  the  call  structure  indicate  recursion,  rou¬ 
tines  that  are  never  called  indicate  unreachable  code,  and 
attempts  to  call  nonexistent  routines  are  flagged.  The  flow 
graph  can  make  dead  code  evident  indicating  improper  use 
of  boolean  expressions. 

Concerning  security,  one  use  for  control  flow  analysis 
would  be  to  check  for  trap  doors  remaining  from  the  debug¬ 
ging  of  the  software.  If  the  control  flow  analyzer  attaches 
predicate  information  to  the  arcs  of  the  graph,  these  predi¬ 
cates  could  be  examined  for  comparisons  to  string  con¬ 
stants. 
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Although  by  itself  the  technique  finds  only  a  limited 
range  of  flaws,  the  call  graphs  and  flow  graphs  are  essential 
for  data  flow  analysis. 

Data-flow  Analysis 

Data  flow  analysis  inspects  patterns  of  data  use  in  a 
program  exposing  error-prone  design  and  programming 
practices.  Although  data  flow  and  control  flow  analysis  are 
separate  techniques,  most  data  flow  analysis  tools  now 
incorporate  some  form  of  control  flow  analysis  to  untangle 
the  high-level  cc Tirol  structures.  In  the  data  flow  tools 
examined,  contro'  flow  is  an  essential  part  of  the  process. 

Data  flow  techniques  were  originally  used  to  optimize 
code  generated  by  certain  compilers  [17]  and  was  later 
applied  in  static  analysis  of  software.  This  technique  has 
been  applied  in  software  validation  and  documentation  of 
Fortran  programs  (Its],  and  several  tools  have  been 
developed  (18,  26).  Data  flow  based  tools  have  also  been 
developed  for  other  languages  including  PL/1  (23], 

Data  flow  analysis  searches  for  anomalies  in  the  source 
code.  An  anomaly  exists  when  a  variable  is  used  in  a  way 
that  is  inconsistent  with  the  previous  or  subsequent  uses  of 
that  variable  in  the  program. 

A  typical  data  flow  analysis  tool  must  first  parse  the 
source  code  and  generate  an  internrl  representation  of  the 
program,  usually  in  the  form  of  a  tree.  Second,  a  control 
flow  graph  of  the  software  is  created  with  attached  varlabte 
information.  This  data  is  used  to  perform  the  data  flow 
analysis. 

The  various  tools  that  utilize  data  flow  analysis  differ 
in  the  errors  they  report,  but  in  general,  the  errors  which 
can  be  found  are: 

1)  reference  to  variables  not  defined  or  set; 

2)  variables  set  but  not  defined; 

3)  variables  set  and  not  used  (or  set  and  then 
set  again  without  being  used  between  the 
two  settings); 

4)  all  of  the  errors  listed  under  pattern 
directed  analysis; 

6)  all  of  the  errors  listed  under  control  flow 
analysis  if  performed. 

It  should  be  noted,  however,  that  the  technique  will 
allow  any  specified  sequence  of  statements  to  be  found.  In 
this  respect,  data  flow  analysis  holds  the  most  potential  in 
security  aualysis.  The  objective  is  to  characterize  a  security 
flaw  a3  a  sequence  of  statements,  and  then  search  for  that 
sequence. 

In  this  respect,  the  data  flow  tools  can  find  the 
security-related  errors  reported  under  pattern-directed 
analysis.  Additionally,  patterns  that  are  uot  obvious  due  to 
the  control  flow  of  the  program  may  be  found.  An  example 
of  such  a  pattern  is  the  class  of  errors  characterized  by 
Bisbey  as  inconsistencies  of  a  single  data  value  over  time 
[4].  In  this  class  of  errors,  a  data  value  is  rendered  incon¬ 
sistent  between  two  operations.  More  specifically,  the  data 
value  is  changed  between  pairs  of  refences.  The  general  pat¬ 
tern  specified  is: 

1)  find  an  operation  L  which  either  fetches 
or  stores  into  a  cell  X; 

2)  find  an  operation  M  that  fetches  cell  X; 

3)  operation  M  is  critical  (security  related); 

4)  operation  L  occurs  before  operation  M. 

Step  4  requires  that  the  control  flow  be  part  of  the  analysis. 


Operation  L  must  then  be  examined  to  see  if  it  improperly 
alters  X. 

Othtr  Techniques 

Other  static  analysis  techniques  may  also  prove  useful 
in  detecting  security  related  flaws.  Cross-reference  genera¬ 
tors  can  reveal  misuse  of  variables.  Although  limited  in 
scope,  a  careful  scrutiny  of  the  cross-reference  listing  might 
be  beneficial  in  a  security  analysis.  Global  variable  misuse, 
conflicting  variables  and  useless  variables  are  a  few  of  the 
errors  that  can  be  determined  with  this  technique. 

Various  program  statistics  can  indicate  suspicious  vari¬ 
ables,  i.e.  variables  only  used  once  or  used  repeatedly.  A 
variable  used  only  once  could  be  an  indication  of  a  trap 
door  or  a  once  used  debugging  tool.  Too  many  uses  could 
indicate  misuse  of  the  variable.  The  RISOS  tools  contained 
a  program  to  analyze  the  statistics  of  the  module  under 
examination  specifically  for  the  above  reasons  (0). 

Limitations  of  Static  Analysis 

As  stated  earlier,  although  static  analysis  is  more 
easily  automated  than  dynamic  analysis,  limitations  exist. 
These  limitations  can  usually  be  overcome  by  using 
dynamic  analysis  techniques, 

The  most  obvious  deficiency  is  the  inability  to  fully 
analyze  dynamic  data  types.  Pointers  and  array  variables 
are  currently  difficult  to  handle  correctly  due  to  their 
dynamic  nature.  Current  static  analysis  tools  can  only  treat 
an  array  as  a  single  variable,  since  they  cannot  know  the 
bounds  of  the  array  in  some  languages.  In  some  cases, 
pointers  cannot  be  treated  at  all.  The  indices  of  arrays  and 
the  objects  of  the  pointers  may  not  be  known  until  execu¬ 
tion.  Desk  checks  must  still  bn  performed  on  the  code  to 
analyze  the  use  of  dynamic  data  types. 

Another  deficiency  is  the  handling  of  recursive  and 
concurrent  procedures.  Some  of  the  control  flow  analysis 
and  data  flow  analysis  techniques  can  follow  recursion  to  a 
pre-deflned  level,  but  only  at  an  enormous  cost  in  resources. 
Concurrent  processing  is  a  current  research  area  in  static 
analysis,  but  the  technology  has  not  yet  filtered  down  to 
available  tools.  [25] 

Specific  Tools 

Various  tools  currently  available  through  government 
or  industry  will  perform  the  analyses  discussed  above. 
While  many  of  the  tools  are  still  experimental  in  nature, 
others  are  proving  to  be  useful  production  tools  in  analyz¬ 
ing  software  for  bugs. 

FCAP,  briefly  discussed  above,  Is  a  tooi  based  on  com¬ 
plexity  metrics.  In  addition  to  calculating  McCabe’s  metrics 
and  calculating  the  values  needed  for  Halstead's  metrics, 
FCAF  will  calculate  additional  metrics,  i.e.  number  of  com¬ 
ment  lines,  number  of  executable  lines,  number  of  entry 
and  exit  points,  number  of  forward  and  backward  branches, 
number  of  conditional  branches  and  more.  FCAP  will  also 
produce  structure  diagrams  of  each  procedure,  variable 
usage  report,  calls  report  (all  call9  from  each  procedure 
within  a  module),  and  an  undefined  external  variables 
report. 

The  tool  is  written  in  Fortran  and  analyzes  Fortran 
source  code  (VAX,  PDP-11,  SKU  Fortran  and  RATFOR). 
It  is  interesting  to  note  that  the  tool  was  used  to  test  itself. 
In  addition  to  FCAP,  the  U.S.  Army  Electronic  Proving 
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Ground  has  also  written  similar  tools  to  analyze  C  and 
various  assembly  languages. 

Weiser’s  Data  Flow  Sheer  is  an  experimental  tool  that 
performs  data  flow  analysis  on  Fortran  programs  [26,  27). 
The  program  will  create  a  data  flow  “slice’'  on  each  vari¬ 
able  in  a  write  statement.  These  slices  will  contain  all  state¬ 
ments  which  affect  the  variable  being  sliced  on,  essentially 
exposing  the  data  flow  to  a  variable. 

RXVP  is  a  comprehensive,  production  tool  by  General 
Research  Corporation  which  provides  static  and  dynamic 
analysis  for  large  Fortran  programs  [22].  This  tool  per¬ 
forms  syntax  and  structural  analysis  to  detect  inconsisten¬ 
cies  in  program  structure  and  use  of  variables,  The  tool 
generates  call  graphs,  cross-reference  listings,  variable  usage 
reports  (set,  used,  set  and  used),  and  I/O  reports  (shows  all 
I/O  statements). 

The  above  survey  gives  a  sampling  of  the  various  func¬ 
tions  available  in  static  analysis  tools.  Many  other  tools  are 
available  which  perform  similar  functions 
[3,  5,  8,  11,  12,  13,  14,  28,  24,  23,  21,  18]. 

Plans 

In  the  next  phase  of  this  research,  various  static 
analysis  tools  will  be  applied  to  programs  seeded  with  secu¬ 
rity  flaws.  The  sample  programs  will  be  medium-sized  mili¬ 
tary  application  programs  written  in  Fortran.  Fortran  was 
picked  since  many  of  the  tools  analyze  that  language.  Also, 
sample  programs  written  in  Fortran  arc  more  readily  avail¬ 
able. 

The  result  of  this  effort  will  be  a  classification  of  the 
types  of  security  errors  that  cau  be  found  using  static 
analysis  tools,  and.  equally  important,  a  classification  of 
those  security  errors  that  cannot  be  found  with  these  tools. 

Next,  dynamic  analysis  tools  will  be  investigated  and 
classifications  will  again  be  made.  Further  research  may 
extend  the  existing  tools  to  create  a  set  of  tools  whose 
specific  function  will  be  to  analyze  the  security  characteris¬ 
tics  of  software. 

Conclusion 

Since  there  is  a  large  body  of  existing  military  software 
that  cannot  reasonably  be  subjected  to  formal  proof,  apply¬ 
ing  analysis  tools  to  this  software  can  help  assure  that  the 
software  is  free  of  some  classes  of  exploitable  security  flaws. 
The  technique  may  also  prove  useful  in  obtaining  a  B1 
“Orange  Book”  rating  from  the  National  Computer  Secu¬ 
rity  Center.  The  Bl  rating  requires  (section  3.1. 3.2.1)  that 
the  source  code  be  subjected  to  “thorough  analysis  and 
testing”  to  uncover  security  flaws  [7]. 

Further  research  is  needed  to  extend  the  existing  tools 
in  order  to  remove  deficiencies  and  to  make  the  tools 
security-specific.  With  these  techniques,  some  assurance  can 
be  made  about  the  security  characteristics  of  a  program. 
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Abstract 


In  this  paper  we  review  the  Bell-LnP3dula  model  for  se¬ 
cure  systems,  which  includes  the  definition  of  states,  state 
transitions  and  axioms  (properties).  The  interpretation  of  the 
model  states  and  state  transition  in  Secure  Xenix  is  defined, 
and  the  access  control  mechanisms  of  Secure  Xenix  are  shown 
•o  satisfy  the  Bell-LaPadula  axioms.  The  discretionary  secu¬ 
rity  and  the  activation  axioms  of  Secure  Xenix  arc  a  superset 
of  those  defined  in  the  Bell-LaPadula  model, 


1.  Introduction 

We  define  the  interpretation  of  the  Bell-LaPadula  secu¬ 
rity  model  [Bell76]  in  Secure  Xenix  [Gligor  86).  The  interpre¬ 
tation  explains  how  the  protection  mechanisms  of  the  Secure 
Xenix  TCB  implement  the  model.  Since  the  description  of  the 
Bell-LaPadula  model  is  formal,  and  since  the  Bell-LaPadula 
model  is  proven  sufficient  to  enforce  a  specific  DoD  security 
policy,  the  interpretation  of  the  model  in  Secure  Xenix  repre¬ 
sents  prima  facie  evidence  that  the  design  of  the  Secure  Xenix 
TCB  follows  that  policy. 

The  interpretation  of  the  Bell-LaPadula  model  and  the 
access  control  mechanisms  of  Secure  Xenix  are  shown  to  sat¬ 
isfy  the  model’s  axioms.  After  that,  one  only  needs  to  demon¬ 
strate  that  the  individual  kernel-call  specifications  (i.e.,  ker¬ 
nel  DTLSs)  preserve  the  ss-,  *-,  ds-properties,  compatibility, 
tranquility,  and  activation  properties  under  the  defined  in¬ 
terpretation.  The  definition  of  the  (Bell-LaPadula)  model 
interpretation  is  required  for  B2-aecure  systems.  In  addition 
to  the  interpretation,  the  demonstration  that  the  individual 
kernel  DTLS/FTLS  preserve  the  above-mentioned  properties 
would  be  required  for  B3/A1  secure  systems  (i.e.,  “A  con¬ 
vincing  argument  shall  be  given  that  the  DTLS  is  consistent 
with  the  model”  c.f.  [TCSEC-  83]  p.  39). 

In  section  2  of  this  paper  we  review  the  formal  definition 
of  the  Bell-LaPadula  model  including  the  notions  of  system 
state,  state  transitions,  model  axioms,  secure  system  state, 
and  secure  systems.  In  section  3  we  define  the  Secure  Xenix 
interpretation  of  the  model  and  show  that  the  access  con¬ 
trol  mechanisms  of  Secure  Xenix  satisfy  the  model  axioms. 
Section  4  contains  the  conclusion,  and  section  5  contains  the 
references. 
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2.  Review  of  the  Bell-LaPadula  Model 

The  Bell-LaPadula  model  is  a  “state  transition”  model. 
That  is,  the  model  defines  formally  system  states  and  rules 
(actions  or  operations)  that  move  the  system  from  state  to 
state.  Furthermore,  the  model  includes  four  axioms  that  must 
also  be  preserved  by  every  state  and  by  applications  of  rules 
to  system  states. 

2.1.  System  Stat 

A  system  state  v  is  an  element  of  the  set  V  —  (B  x  M  x 
F  x  H)  that  is  defined  below.  _ 

B  is  the  set  of  current  accesses  and  is  a  subset  of  the  set 
(S  X  0  x  A),  where  S  is  the  set  of  subjects,  0  is  the  set  of 
objects  and  A  is  the  set  of  access  privileges  (modes)  defined 
in  the  system.  The  set  B  defines  the  access  privileges  each 
subject  has  to  each  object  currently. 

M  is  the  access  matrix.  It  consists  of  elements  M,y  €  A 
that  define  the  set  of  access  privileges  subject »  may  have  to 
object  j. 

F  is  a  three-component  security  function ;  the  first  com¬ 
ponent,  f„  assigns  a  maximum  security  level  (clearance)  to 
earti  subject,  the  second  component,  assigns  the  security 
level  (classification)  to  each  object;  and  the  third  component, 
/„,  assigns  the  current  security  level  of  each  subject.  Note 
that  /,  >  /„. 

H  is  the  current  object  hierarchy.  It  iB  a  subset  of  all 
functions  /£  from  objects  O  to  the  power-set  of  objects  O, 
PO,  subject  to  the  following  two  restrictions: 

(1)  =  *,  and 

(2)  there  does  not  exist  a  set  {Oi,02,...,0u,}  of  ob¬ 
jects  such  that  Or+i  €  R(Or),  1  <  r  ^  an{l 
0«j+i  =  Oi. 

(The  above  two  conditions  imply  that  the  current  object  hi¬ 
erarchy  is  a  collection  of  rooted,  directed  trees  and  isolated 
points.  They  rule  out  objects  with  multiple  parents  at  differ¬ 
ent  levels,  and  cycles.  If  11  is  a  tree  structure,  then  Op.  is  an 
object  called  the  root  for  which  if  (Or)  ■/■  <t>  and  0,  €  B  (On) 
for  any  Or  6  O.  Furthermore,  0;  is  a  superior  of  Oj  if 
Oj  6  H[pi). 

2.2.  State  Transitions 

The  system  transition  from  state  to  state  is  defined  by 
a  set  of  rules  (operations)  that  are  requested  by  subjects  on 
system  states.  A  rule  is  a  function  that  specifies  a  decision 
(output)  and  a  next-state  for  every  state  and  every  request 
(input).  Thus,  a  rule  p  is  defined  as: 

pt  RxV  —*  D  xV,  where 

R  x  V  is  the  set  of  request-state  pair  (input)  defined  in  the 
system  for  every  request,  and  D  x  V  is  the  set  of  decision- 
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state  pair  output  defined  in  the  system  for  every  request.  R 
is  the  set  of  request  invocations  defined,  and  D  is  the  set 
(Yes,  No,  ?,  Error)  of  request  outcomes.  “Yes”  (“No”)  means 
that  the  request  has  (not)  been  executed.  The  “?”  outcome 
means  that  any  other  exceptional  condition  detected  during 
the  application  of  the  rule  p  (e.g.,  table  overflow,  etc.). 

Let  {pi,. . .  ,p<}  be  a  set  of  rules.  The  relation  W  is  set 
of  state  traditions  and  is  defined  for  any  if*  £  if,  Dm  €  D 
and  Y*€Vby: 

(if*,  Dm,  V*,  V)  €  WM  iff  Dm  ?,  DM  $  Error,  and 

(Z)m,  V*)  =  pi(Rk,  V )  for  a  unique  1  <  i  <  s; 

2.3.  Systems,  System  Appearance,  System  Actions 

Let  T  be  the  set  of  positive  integers.  X  is  defined  as  the 
set  of  all  request  sequences,  namely  the  set  of  all  functions 
from  T  to  if;  Y  is  defined  as  the  set  of  all  decision  sequences, 
namely  the  set  of  all  functions  from  T  to  D\  Z  is  defined  as 
the  set  of  all  state  sequences,  namely  the  set  of  all  functions 
from  T  to  V. 

A  system,  £(iJ,D,VY,  z0),  is  a  subset  of  X  x  Y  x  Z  such 
that  ( x,y,z )  £  ]> 2{R,D,W,z0 )  if  and  only  if  {xi,yt,zt,zt-i)  6 
W  for  each  t  £  T,  where  zo  is  the  initial  state.  (Note  that 

Zi)  ue  individual  elements  of  sequences  x(y,z).] 

A  system  appearanct  is  defined  as  each  triple  (x,y,  z) 
such  that  (s,j i,z)  €  £j(.ft,.D,H'',x<)),  x  e  X,  j/  €  Y,  z  Q  2. 

A  system  action  is  defined  as  each  quadruple 
( Xt,Vt,zt,zt-i )  £  W,  where  Xt,yt,zt  are  the  i-th  request, 
decision,  and  state  in  the  sequences  x  £  X,  y  &Y,  z  &  Z. 

Alternatively,  (R,,Dj,v*,V)  eifxDxVxVisan 
action  of  ]T(R,D,W,z0)  iff  there  is  an  appearance  (x,y,z)  £ 
52{R,D,W,z0)  and  some  t  €  T  such  that  (Ri,Dj,v‘,  v)  = 
(*i,y«>*t,*i-i). 

2.4.  Model  Axioms 

The  axioms  of  the  Bell-LaPadula  model  require  the  def¬ 
inition  of  the  access  privilege  set  A.  In  the  model,  A  =  { 
read,  write,  execute,  append  }  =  {r,  to,  e,  a}.  The  meaning 
of  these  privileges  is  defined  in  the  model  in  terms  of  the  abil¬ 
ity  to  “observe"  or  “alter”  the  state  of  objects  and  subjects 
as  follows: 

e  (execute)  access  =  neither  observation  nor  alter¬ 
ation 

r  (read)  access  =  observation  with  no  alteration 
a  (append)  access  =  alteration  with  no  observation 
w  (write)  access  =  both  observation  and  alteration. 

The  first  two  of  the  four  axioms  (also  called  “properties” 
in  Bell  (76))  use  the  above  access  privilege  definitions.  An 
additional  axiom,  called  the  “tranquility  principle,”  is  defined 
in  [Bell  73] .  This  axiom  has  been  removed  from  [Bell  76). 

2.4.1.  The  Simple  Security  (ss)  Property 

A  system  state  v  =  (6,  M,  f,  H)  satisfies  the  ss-property 
iff,  for  each  element  6  £  B  that  has  an  access  privilege  of  read 
or  write,  the  maximum  clearance  of  the  subject  dominates  the 
classification  of  the  object;  or  alternatively: 

An  element  (s,o,£)  €  B  satisfies  the  ss-property  relative 
to  the  security  function  /  iff 

(i)  S.  —  <  or  a,  or 

(ii)  £  =  r  or  w  and  fs(s)  >  f0{o). 


The  above  two  definitions  restrict  the  subject  access  to 
objects  based  on  object  classifications  and  subject  maximum 
clearances  whenever  subject  accesses  to  objects  include  “ob¬ 
servation”  of  the  object  state.  Also  note  that  the  ss-property 
restricts  subjects  from  having  direct  access  to  information  for 
which  they  are  not  cleared. 

2.4.2.  The  ‘-Property 

A  system  state  v  =  (6,  M,  f,  H)  satisfies  the  *-property 
relative  to  the  set  of  subjects  S'  C  S  iff,  for  each  element 
[s,o,  x)  £  B : 

(i)  x  =  a  =S>  /c(sl  <  fo(o) 

(ii)  x  =  w  =>■  /c(s)  =  /0(o) 

(iii)  x  =  r  ==>  /c(s)  >  /0(o);  where  S'  is  the  set  of 

untrusted  subjects. 

The  above  property  is  intended  to  prevent  unauthorized 
flow  of  information  from  higher  security  levels  to  lower  ones 
In  particular,  the  *-property  prevents  an  untrusted  subject 
from  having  simultaneously  privileges  to  “observe”  informa¬ 
tion  at  some  level  and  to  “alter”  information  at  a  lower  level, 
namely  ((s,o,-,o),(s,o,,r)  €  B)  =*■  /0(o,)  >  fo{oj).  This 
property  represents  a  restatement  of  the  ‘-property,  and  is 
used  as  the  ‘-property  definition  in  [Feiertag  77).  Note  that, 
trusted  subjects  (i.e.,  subjects  not  in  S')  need  not  be  bound 
to  the  ‘-property  relative  to  S'. 

2.4.3.  Discretionary  Security  (ds)  Property 

A  system  state  v  =  (6,  M,  f,  H)  satisfies  the  ds-property 
iff,  for  every  element  («i,0;,£)  6  B,  £  £  M,j . 

2.4.4.  Compatibility  Property 

The  object  hierarchy  II  maintains  compatibility  iff,  for 
any  0„0,  6  O  and  Oy  €  17(0,),  /0(Oy)  >  /0(O,).  This 
axiom  is  also  called  the  “nondecreasing  level”  axiom  for  the 
object  hierarchy. 

2.4.5.  Tranquility  Principle 

The  original  version  of  the  Bell-LaPadula  model  [Bell 
73]  also  contained  the  “tranquility”  principle.  This  principle 
(axiom)  states  that  a  subject  cannot  chai  ge  the  security  level 
of  active  objects.  Of  course,  this  is  defined  relative  to  the 
untrusted  subjects  S'. 

This  axiom  has  been  removed  from  the  1976  version  of 
the  Bell-LaPadula  model  to  allow  controlled  changes  of  se¬ 
curity  levels  of  active  objects.  The  rules  that  control  such 
changes  depend  on  specific  applications  (e.g.,  mail,  guards, 
etc.)  and  differ  from  system  to  system. 

2.4.6.  Activation  Axioms 

Object  activation/deactivation  refers  to  the  creation  and 
destruction  of  objects.  The  dynamic  creation/destruction  of 
objects  in  the  Bell-LaPadula  model  would  cause  the  domain 
of  the  classification  function  f0  and  the  size  of  the  access 
matrix  M  to  vary  dynamically.  To  avoid  this,  the  entire  set 
of  objects  ever  used  arc  considered  extant  in  either  active 
or  inactive  form.  Furthermore,  objects  are  considered  to  be 
labeled  in  both  forms  [Bell74]. 

However,  the  use  of  the  above  convention  requires  the 
specification  (l)  of  a  subject’s  access  to  an  inactive  object,  (2) 
of  the  state  of  newly  activated  objects,  (3)  of  the  classification 
of  newly-activated  objects,  and  (4)  of  the  object  deactivation 
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rules.  Specification  (1)  is  necessary  because  active  and  in¬ 
active  objects  are  assumed  to  coexist  in  0.  Since  the  model 
defines  subjects’  access  to  active  objects,  it  must  also  define 
subjects’  access,  or  lack  thereof,  to  inactive  objects.  If  left 
unspecified,  such  access  may  cause  security  breaches  in  real 
implementations.  Specification  (2)  is  necessary  because  inac¬ 
tive  objects  have  states  (since  they  exist  in  O).  Thus,  their 
activation  must  specify  the  relationship  between  the  state  of 
an  inactive  object  and  its  state  at  activation.  Similarly,  spec¬ 
ification  (3)  is  necessary  because  inactive  objects  also  have 
a  classification  in  the  model,  and  their  classification  while 
inactive  might  “not  match  the  requirements  of  the  request¬ 
ing  subjects”  [Bell  74).  Furthermore,  their  classification  may 
conflict  with  the  compatibility  axiom  (Bell  76).  Specification 
(4)  is  also  necessary  because  the  object  deactivation  (destruc¬ 
tion)  rules  are  security  relevant.  (As  shown  in  section  3.1.7 
the  destruction  of  upgraded  directories  may  not  take  place  at 
the  level  where  they  are  read  or  written.) 

Feiertag,  Levitt  and  Robinson  [Feiertag  77)  attribute  two 
activation  axioms  to  Bell-LaPadula  [Bell  74)  that  specify  only 
a  subject’s  access  to  one  inactive  object  and  the  state  of  a 
newly-activated  object.  The  two  activation  axioms  are: 

(i)  Non-accesaability  of  Inactive  Objects  -  A  subject,  can¬ 
not  read  the  contents  of  an  inactive  object;  and 

(ii)  Rewriting  of  Newly  Activated  Objects  -  A  newly  ac¬ 
tivated  object  is  given  an  initial  state  that  is  independent  of 
the  state  of  any  previous  incarnations  (n.a.,  activations)  of 
the  object,  (n.a.,  This  axiom  implies  that  the  “object  reuse” 
requirement  of  [TCSEC  83]  is  satisfied.) 

The  two  activation  axioms  can  be  expressed  succinctly 
as: 

(i)  Let  O  -  O'  U  O"  where  0'(0")  =  active  (inactive) 
objects  and  O'  n  O"  —  $ 

[V(s,o,i)€  B,  o  e  O"]  (x  r  and  x  f  w) 

(ii)  Let  nc.v(o)  =  { O "  :=  O"  —  o  and  O'  :=  O'  +  o} 

and  CALL[Si,  new(o))  be  t.he  invocation  of  the  primitive 

“new"  by  S,', 

CALLjSi,  ncw(o)]  =>  state)new(o))  ^  g)state(o))  for 
any  function  g  and  state  (o). 

2.5.  System  Security 

A  state  sequence  2  —  is  a  secure  state  se¬ 

quence  iff  zt  is  a  secure  state  for  each  i  £  T. 

A  system  appearance  ( x,y,z )  6  £(.R,.D,l'F1z0)  is  a  se¬ 
cure  appearance  iff  2  is  secure  state  sequence. 

A  system  ^2(R,D,W,z0)  is  a  secure  system  iff  every  ap¬ 
pearance  ( x ,  y,  z)  is  a  secure  appearance. 

An  equivalent  definition  of  secure  systems  can  be  given 
by  stating  that  a  system  satisfies  the  first  three  security  ax¬ 
ioms,  namely  the  ss-property,  the  ‘-property,  and  the  ds- 
property.  The  following  three  theorems  form  the  basis  for 
an  alternate  definition  of  secure  systems. 

Theorem  Al. 

The  system  £)(./?,  D.tV.zo)  satisfies  the  ss-property 
for  any  initial  state  zo  that  satisfies  the  ss-property 
iff  W  satisfies  the  following  conditions  for  each  action 


(i)  each  ( S ,  0,x)  6  6*  -  b  satisfies  the  sa-property  rela¬ 
tive  to  /* ;  and 

(ii)  each  ( S,Otx )  €  b  that  does  not  satisfy  the  ss- 
property  relative  to  f*  is  not  in  6*. 

Theorem  A2. 

A  system  ]£(.R,  D,  W,  zo)  satisfies  the  ‘-property  relative 
to  S'  C  S  for  any  initial  state  Zo  that  satisfies  the  ‘-property 
relative  to  S'  iff  W  satisfies  the  following  conditions  for  each 
action  lR;,Dh(b\M\r,H'),  (b,M,f,H) |: 

(i)  for  each  S'  C  S,  aoy  (S,0,x)  e  4*  -  6  satisfies  the 
‘-property  with  respect  to  S'\  and 

(ii)  for  each  S'  C  S,  if  (£,  0,x)  6  4  does  not  satisfy  the 
‘-property  relative  to  S',  then  (s,  o,x)  §£  6*  —  6. 

Theorem  A3. 

A  system  ^2(R,D,W,zq)  satisfies  the  ds-property  iff  the 
initial  state  zo  satisfies  the  ds-property  and  W  satisfies  the 
following  conditions  for  each  action  \Ri,D],(b'  ,M‘ ,  f  ,H‘), 
(6,M,/,ff)): 

(i)  if  (Sk,  Oe,x)  €  6*  —  4,  then  x  €  and 

(ii)  if  (Sk,  Ot,xj  €  4  and  x  #  Mfa,  the  (Sk,  Ot,x)  £  4*. 

The  proofs  to  the  above  three  theorems  can  be  found  in 
(Bell76,  pp.  89-94). 

Corollary  Al  [Basic  Security  Theorem). 

A  system  ^(R,  D,W,  20)  is  a  secure  system  iff  zo  is  a 
secure  state  and  W  satisfies  the  conditions  of  theorems  AX, 
A2,  and  A3  above. 

Theorems  A4-A6  and  A7-A9  of  [Bell76,  pp.  94-  97)  rep¬ 
resent  restatements  of  Theorems  A1-A3  focusing  on  (l)  prop¬ 
erties  of  sets  of  system  actions  of  W,  and  on  (2)  properties 
of  individual  states  of  V,  respectively.  In  contrast,  Theorems 
A1-A3  focussed  on  properties  of  the  current  access  sets  of 
B.  Similarly  corollaries  A2  and  A3  are  the  corresponding 
restatements  of  corollary  Al.  Theorem  10  restates  the  re¬ 
sults  of  the  Theorems  A1-A3,  A4-A6,  and  A7-A9  in  terms  of 
property-preserving  rules  p. 

The  need  for  the  alternate,  but  equivalent  theorems,  be¬ 
comes  apparent  when  one  needs  to  construct  proofs  of  real 
systems.  For  example,  in  systems  whose  kernel  enforces  se¬ 
curity,  it  is  substantially  more  convenient  to  prove  Theorems 
A4-A6  or  A10  than  Theorems  A1-A3  or  A7-A9.  The  reason 
is  system  actions  or  rules  can  be  easily  identified  with  kernel 
calls  and  their  effects  on  the  system  states. 

3.  The  Interpretation  of  the  Bell-LaPadula  Model 

The  interpretation  of  the  Bell-LaPadula  model  in  Secure 
Xenix  consists  of  a  description  of  the  notion  of  system  state, 
and  state  transition  in  Secure  Xenix.  Furthermore,  it  in¬ 
cludes  the  definition  of  the  initial  state  and  an  argument  that 
explains  why  the  mandatory  and  discretionary  access  control 
of  Secure  Xenix  implies  that  the  axioms  of  the  Bell-LaPadula 
model  are  satisfied. 

3.1.  The  Interpretation  of  the  System  State 

The  interpretation  of  the  system  state  requires  the  iden¬ 
tification  of  the  state  components  B  =  S  x  O  x  A,  M ,  F , 
and  H  in  Secure  Xenix. 


115 


3.1.1.  Secure  Xenix  Subjects  (S) 

Processes  arc  the  only  type  of  subject  in  Secure  Xenix.  A 
process  may  create  and  destroy  objects,  may  activate  and  de¬ 
activate  them,  may  change  the  discretionary  privileges  of  ob¬ 
jects  in  the  access  matrix,  may  change  the  current  access  set, 
and  may  change  the  object  hierarchy.  However,  processes  may 
not  change  the  security  level  of  objects.  All  changes  a  process 
makes  to  the  system  state  are  constrained  to  satisfy  compat¬ 
ibility,  tranquility,  ss-property,  *-property,  and  ds-property. 
This  is  discussed  in  detail  below. 

Processes  are  created  at  login  time  or  by  other  processes. 
A  process  is  identified  by  a  unique  process  identifier  and  its 
user  is  identified  by  a  non-reusable  UID  and  GID  [Gligor86]. 
The  effective  UID  and  GID  of  a  process  are  used  in  all  discrete 
unary  access  control  decisions.  Each  process  contains  a  secu¬ 
rity  label  that  is  used  in  mandatory  access  control  decision. 
Process  labeling  is  discussed  below  in  the  section  describing 
the  interpretation  of  the  security  function  in  Secure  Xenix, 
and  the  use  of  the  real  and  effective  UID  and  GID  is  dis¬ 
cussed  in  the  interpretation  of  discretionary  access  control. 

3.1.2.  Secure  Xenix  Objects  (O) 

The  user-created  objects  of  Secure  Xenix  are:  files, 
special  files  (devices),  directories,  pipes,  message  queues, 
semaphores,  shared  memory  segments,  Xenix  semaphores, 
Xenix  shared  data  segments,  ACLs,  and  processes.  Secure 
Xenix  also  includes  system-created  and  maintained  objects 
such  a3  the  special  files  (devices)  that  can  be  opened  or  closed 
by  user  processes.  Trusted  processes  create,  maintain,  and 
use  similar  objects  as  those  of  the  users. 

(1)  Files,  Special  Files,  Pipes, 

Xenix  Semaphores,  Xenix  Data  Segments,  and  ACLs 

Files  are  containers  of  information  managed  by  the  Se¬ 
cure  Xenix  kernel.  Files  are  protected  by  either  ACLs  or  by 
protection  bits  associated  with  file  i-nodes.  The  security  label 
of  each  file  is  represented  in  its  i-node. 

The  special  files  are  used  to  represent  devices  and  can 
be  opened  or  closed  by  user  processes.  In  the  case  of  special 
files  the  object  activation  and  deactivation  are  equivalent  to 
the  opening  and  closing  of  a  device.  In  all  other  aspects  the 
special  files  function  as  the  user-created  files. 

The  Xenix  shared  data  segments  have  similar  function  to 
that  of  the  files  and  are  represented,  protected,  and  labeled  in 
a  similar  way.  The  difference  is  that  the  shared  data  segments 
allow  asynchronous  processes  to  synchronize  their  read  and 
write  accesses  to  segment  data,  and  that,  unlike  files  that  are 
shared  on  a  per-copy  basis,  shared  data  segments  are  shared 
on  a  per-original  basis. 

Named  pipes  function  as  “unbounded”  communication 
buffers  and  are  represented,  protected,  and  labeled  in  a  simi¬ 
lar  way  as  the  files.  The  difference  between  named  pipes  and 
shared  data  segments  is  that  named  pipes  impose  producer- 
consumer  process  synchronization  to  prevent  underflow  con¬ 
ditions. 

Semaphores  are  objects  that  allow  the  synchronization 
between  asynchronous  processes  and  have  similar  representa¬ 
tion,  protection  and  labeling  to  that  of  files. 

Access  Control  Lists  (ACLs)  are  objects  used  for  the  dis¬ 
cretionary  protection  of  files  (Gligor86j  and  are  represented 


as  specially-protected  files  by  the  kernel.  Each  ACL  is  asso¬ 
ciated  with  it3  file  uniquely  for  the  lifetime  of  the  file.  The 
association  is  maintained  by  the  kernel.  The  ACLs  are  la¬ 
beled  with  the  same  label  as  that  of  the  file  they  protect. 
They  are  discussed  in  detail  in  the  section  on  access  matrix 
representation. 

(2)  Directories 

Directories  are  containers  for  files,  special  files,  pipes, 
Xenix  semaphores,  Xenix  Data  Segments,  ACLs,  and  other 
directories.  They  form  the  building  blocks  for  the  system 
hierarchy.  Directories  are  maintained  and  protected  by  the 
Secure  Xenix  kernel  and  are  represented  in  a  similar  way  to 
that  of  files.  The  directories  that  contain  special  files  and 
ACLs  are  system  created/destroyed  whereas  the  rest  of  the 
directories  are  created  and  destroyed  by  users.  A  directory 
that  contains  an  object  is  called  a  parent  directory.  A  special 
directory  called  the  root  is  the  highest  directory  in  the  parent 
chain.  It  is  its  own  parent.  It  has  no  ACL  and  is  always 
“search” -able  by  all  users. 

(3)  Message  queues,  Semaphores,  Shared  Memory  Seg¬ 
ments,  and  Processes 

The  objects  in  this  group  do  not  have  file  system  rep¬ 
resentation.  The  System  V  semaphores  and  rhared  memory 
segments  have  the  same  function  as  their  Xenix  correspon¬ 
dents.  The  message  queues  are  containers  for  messages  and 
are  used  primarily  for  requests  to  server  processes.  Processes 
are  created  and  destroyed  by  their  parent  processes  an  .1  are 
identified,  labeled,  and  protected  in  the  same  way  as  that 
used  for  their  parents. 

All  objects  mentioned  above  are  activated  when  they  are 
created  and  deactivated  when  they  axe  destroyed.  Exceptions 
to  this  rule  are  the  special  files,  which  activated  when  they 
are  opened  and  deactivated  when  they  are  closed.  Special 
files  (devices)  cannot  be  crcatcd/destroycd  by  users.  This  is 
important  in  the  interpretation  of  the  activation  axiom  (viz. 
section  3.7). 

3.1.3.  Access  Privilege  Set  of  Secure  Xenix 

(A) 

The  basic  set  of  access  privileges  in  Secure  Xenix  con¬ 
sists  of  the  read,  execute,  write,  and  null  privileges.  (An 
additional  privilege,  setuid-gid,  is  defined  for  executable  files. 
This  privilege  is  discussed  in  section  3.3  below).  These  privi¬ 
leges  are  visible  to  the  user  and  are  interpreted  by  the  kernel 
differently  for  different  objects.  Thus,  the  actual  privilege  set 
is  substantially  larger  than  the  basic  set  above.  In  this  sec¬ 
tion  we  define  the  access  privileges  for  each  type  of  object  of 
Secure  Xenix  and  its  relationship  with  the  access  privileges 
(modes)  of  the  Bell-LaPadula  model. 

In  examining  the  relationship  between  the  Bell-LaPadula 
model  privileges  and  the  Secure  Xenix  privileges  it  should  be 
noted  that  the  e  (execute)  privilege  of  the  model  does  riot 
have  any  correspondent  in  Secure  Xenix  (nor  in  other  sys¬ 
tems  [Bell76,  footnote  on  p.  11]) .  Similarly,  the  null  privilege 
of  Secure  Xenix  is  not  explicitly  represented  in  the  model. 
Furthermore,  some  of  the  model  privileges  have  no  meaning 
for  some  of  the  Secure  Xenix  objects  and  have  no  represen¬ 
tation  among  the  privileges  define  for  those  objects.  (These 
cases  are  denoted  by  the  phrase  ”no  meaning”  in  the  corre¬ 
spondence  tables  below).  Other  model  privileges  that  have 
no  meaning  for  some  Secure  Xenix  objects  have  representa- 
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tion  among  the  access  privileges  for  those  objects,  however 
the  access  authorization  mechanisms  ignore  their  representa¬ 
tion.  This  means  that  none  of  the  operations  defined  on  those 
objects  may  be  authorized  by  the  ignored  privileges.  (These 
cases  are  denoted  by  the  phrase  "ignored*  in  the  privilege 
correspondence  tables  below.) 

(1)  File  Access  Privileges 

read  (r)  A  process  granted  read  access  to  a  file  can  execute 
instructions  that  cause  data  to  be  fetched  (read) 
from  the  file  into  processor  or  memory  registers  that 
can  be  manipulated  (e.g.,  copied)  by  users.  The 
read  access  of  the  Bell-LaPadula  model  maps  di¬ 
rectly  into  the  Secure  Xenix  read. 


(2)  Privileges  for  Special  Files,  Pipes,  Message  Queues, 
Shared  Memory  Segments,  Xenix  Shared  Data  Segments  and 
ACLs 

The  privileges  for  these  types  of  objects  are  the  same  and 
have  the  same  meaning  as  the  file  privileges.  They  have  the 
same  relationships  to  the  Bell-LaPadula  privileges  as  those 
of  files  (discussed  above).  The  only  difference  between  the 
privileges  for  this  group  of  objects  and  file  privileges  is  that 
the  execute  privilege  (x)  has  no  meaning  for  this  group  of 
objects  and,  therefore,  this  field  is  ignored  for  all  objects  in 
this  group. 

In  summary: 

Bell-LaPadula  privilege  corresponds  to  this  Group  Privilege : 


write  (w)  A  process  granted  write  access  to  a  file  can  execute 
instructions  that  cause  data  in  the  file  to  be  mod¬ 
ified.  This  access  privilege  differs  from  the  write 
access  in  the  Bell-LaPadula  mode!  in  the  sense  that 
it  does  not  allow  any  observation  of  the  state  of  the 
file  being  modified.  The  append  (a)  privilege  of  the 
Bell-LaPadula  model,  maps  into  the  Secure  Xenix 
write  privilege.  Note  that  the  Secure  Xenix  write 
privilege  is  also  necessary  for  append  operations  to 
files.  The  write  (w)  privilege  of  the  Bell-LaPadula 
model  maps  into  the  read  and  write  privilege  com¬ 
bination  of  Secure  Xenix. 

execute  (x)  A  process  granted  the  "execute”  (x)  privilege  to  a 
file  can  transfer  control  to  that  file  and  cause  por¬ 
tions  of  the  file  to  be  interpreted  and  executed  as 
instructions.  Note  that  the  portions  of  the  file  be¬ 
ing  executed  as  instructions  are  not  stored  in  pro¬ 
cessor  nor  in  memory  registers  from  which  they  can 
he  copied  by  users.  Thus,  the  execute  privilege  dif¬ 
fers  from  the  read  privilege.  Also,  this  access  priv¬ 
ilege  differs  from  the  e  (execute)  access  of  the  Beli- 
LuPadula  model  in  the  sense  that  it  allows  the  ob¬ 
servation  of  the  state  of  the  program  executing  a  file, 
whereas  the  execute  privilege  of  the  Bell-LaPadula 
model  does  not.  The  execute  and  read  combination 
of  the  Bell-LaPadula  model  maps  directly  into  the 
execute  (x)  privilege  of  Secure  Xenix. 

null  (-)  A  process  with  the  null  privilege  for  a  file  cannot 
access  the  file  in  any  way.  The  Bell  LaPadula  model 
doc3  not  include  the  null  privilege  (although  the  ex¬ 
ecute  privilege  semantics  comes  close  to  it). 

setuid-gid  Files  containing  program  code  have  an  additional 
privilege  bit  that  can  change 

(suid-gid)  the  Identity  (i.e.,  UID  or  GID)  of  the  process  while 
executing  in  that  file.  This  is  discussed  in  the  sec¬ 
tion  that  describes  the  discretionary  access  control 
in  Secure  Xenix. 


e  (execute) 
r  (read) 

re  (read  Sc  execute) 
a  (append) 
w  (write) 


r 

x(ignored) 

w 

rw 

null 


(3)  Directory  Privileges 

read  (r)  A  process  granted  read  access  to  a  directory  can 
execute  instructions  that  cause  directory  attributes 
and  contents  to  be  fetched  (read)  from  the  direc¬ 
tory  into  processor  or  memory  registers  that  can  be 
manipulated  (e.g.,  copied)  by  users.  Note  that  no 
information  about  the  objects  named  by  that  direc¬ 
tory  can  be  retrieved.  The  relationship  of  this  access 
to  the  read  access  of  the  Bell-LaPadula  model  is  the 
some  as  that  of  the  files. 


search  (x)  A  process  granted  the  search  privilege  to  a  direc¬ 
tory  can  execute  instructions  that  match  a  given 
string  of  characters  to  those  of  a  directory  entry. 
Note  that  the  search  privilege  is  weaker  than  the 
read  privilege,  which  could  also  be  used  for  search¬ 
ing.  The  read  privilege  of  the  Bell-LaPadula  model 
maps  into  the  search  privileges  with  the  appropriate 
restriction;  i.e.,  the  read  privilege  must  be  restricted 
to  directory-entry  reads.  Also  note  that  the  distin¬ 
guished  Root  directory  has  the  search  privilege  on 
for  all  processes  in  the  system. 

execute  The  execute  privilege  has  no  meaning  for  directories. 
Thus,  the  execute  and  read  privilege  combination  if 
the  Bell-LaPadula  model  has  no  meaning  either  for 
Secure  Xenix  directories.  Note,  however,  that  the 
execute  privilege  bit  is  reassigned  by  the  access  au¬ 
thorization  mechanism  to  the  search  operation  and 
thus  it  denotes  the  search  permission. 

add- 

entry  (w)  A  process  granted  the  add.entry  (w)  privilege  to  a 
directory  can  execute  in 


In  summary: 

delete.entry  (w) 

Bell-LaPadula  privilege  corresponds  to  File  Privilege : 

e  (execute)  — ► 

- 

r  (read)  — * 

re  (read  Sc  execute)  — ► 

r 

X 

(rw) 

a  (append) 

w 

null  (-) 

w  (write)  -♦ 

rw 

—  -► 

null 

structions  that  cause  new  entries  to  be  appended  to 
or  removed  from  that  directory.  The  append  priv¬ 
ilege  (a)  of  the  Bell-LaPadula  model  maps  directly 
into  this  privilege  for  directories. 

The  Bell  LaPadula  write  (w)  access  maps  directly 
into  the  delete.entry  privilege  (rw)  of  Secure  Xenix. 

The  null  privilege  has  the  same  interpretation  for 
directories  as  that  for  files. 
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Btll-LaPadula  privilege*  eorrtipond  to  Directory  Privilege r. 

r  (read)  or 

x  (search  =•=>  restricted  read} 
(x)  no  meaning 
w  (add  entry  or  delete  entry) 
rw 
null 

(4)  Privileges  for  Semaphore*  and  Xenix  Semaphore t 

The  access  privileges  for  System  V  semaphores  are  de¬ 
fined  in  the  same  way  as  those  for  files,  and  their  relation¬ 
ship  to  the  Bell-LaPadulm  privileges  is  the  same  as  that  of 
files.  The  xecute  (x)  privilege  has  no  meaning  for  semaphores 
and  is  ignored  by  the  access  authorization  mechanism.  The 
write  (w)  privilege  in  isolation  has  no  meaning  for  System  V 
semaphores.  Whenever  the  write  privilege  is  on  but  the  read 
privilege  is  off  the  write  privilege  is  ignored  by  the  access 
authorization  mechanisms.  Thus,  the  only  non-null  accesses 
defined  for  System  V  semaphores  are  read  (r)  and  read  and 
write  (rw). 

For  Xenix  semaphores,  the  execute  (x)  privilege  has 
no  meaning  and  is  ignored  by  the  access  authorization 
mechanisms.  Although  the  write  privilege  has  meaning  on 
semaphores  in  general,  the  Secure  Xenix  access  authoriza¬ 
tion  mechanism  reassigns  that  meaning  of  write  to  the  read 
privilege  and  ignores  the  write  privilege,  thus,  the  read  (r) 
privilege  for  Xenix  semaphores  implies  both  observation  and 
alteration  and,  therefore,  it  is  equivalent  to  the  write  (w)  priv¬ 
ilege  of  the  Bell-LaPadula  model,  and  to  rcad&writc  (rw)  in 
Xenix. 

In  summary, 

Bell-LaPadula  Privilege s  correspond  to  System  V  Semaphore 
Privileges 


e  (execute) 
r  (read) 

re  (read  k  execute) 
a (append) 
w  (write) 


e  (execute) 

— * 

— 

r  (read) 

-> 

r  (read) 

re  (read  A  write) 

-~» 

x  (ignored) 

a  (append) 

-* 

w  (ignored  whenever  read  is 

w  (write) 

-* 

rw  (read  and  write) 

— 

— 

null 

Btll-LaPadula  Privileges 

torrespond  to  Xenix  Semaphoi 

Privileges 

e  (execute) 

— * 

r  (read) 

—4 

r  (read) 

a  (r.ppend) 

w  (ignored) 

W  /uieilal 
** 

-  / _ 1  _  _  J 

*  \iv«u  o-t iu  nriiLeJ 

null 

(S)  Privileges  for  Processes 

The  only  privileges  defined  for  processes  (not  to  be  con¬ 
fused  with  the  process  code  file)  are  signal,  kill,  and  null. 
The  signal  and  kill  privileges  are  implemented  implicitly  for 
every  process  and  are  a  stylized  form  of  a  “write"  to  a  process 
body.  The  null  privilege  is  also  implicitly  implemented  by  the 
kernel  through  the  process  isolation  mechanism;  namely,  two 
isolated  processes  have  null  privileges  to  each  other. 


3.1.4.  The  Current  Access  Set  in  Secure 
Xenix  (B) 

The  current  access  set  B  is  a  subset  of  S  x  O  x  A.  In 
Secure  Xenix,  the  current  access  set  is  represented  by  a  per- 
process  data  structure  for  some  types  of  objects  and  by  a  per 
type  data  atructure  for  tome  other  types. 

(1)  The  Per-Process  Component 

The  per-process  component  of  the  current  access  set  con¬ 
sists  of  a  set  of  descriptors  (fd)  stored  in  the  ujofile  structure 
of  the  per-process  u.block.  These  descriptors  point  to  a  file 
table  whose  entries  contain  the  current  access  privileges  of 
the  process  to:  files,  special  files,  ACLs,  named  pipes,  Xenix 
semaphores  and  Xenix  shared  data  segments,  and  directories. 
The  file- table  untries  are  multiplexed  among  objects  of  all  pro¬ 
cesses.  Each  per-process  descriptor  points  to  an  entry  in  the 
file  table.  The  access  privileges  of  each  entry  arc  a  subset  of 
the  privileges  that  the  process  has  to  the  object  (discussed  in 
the  next  section).  Note  that  for  semaphores  and  for  shared 
data  segments  the  current-access-privilege  set  is  the  same  as 
the  process  always  has  to  these  objects;  i.e.,  the  same  as  the 
corresponding  access  matrix  entry. 

(2)  The  Per- Type  Component 

The  per-type  component  of  the  current  access  set  con¬ 
sists  of  special  descriptor*  that  contf  in  the  access  privileges 
available  to  each  process.  These  descriptors  are  semid-ds 
for  System  V  semaphores,  msgid.ds  for  message  queues,  and 
shemidjds  for  shared  memory  segments.  The  ipc.perm  field 
of  these  descriptors  contain  the  access  privileges  a  process  has 
to  these  objects.  Here,  as  for  Xenix  semaphores  and  shared 
data  segments,  the  current  access-privilege  set  is  the  same  as 
those  the  process  always  i.as  to  these  objects. 

3.1.5.  The  Access  Matrix  in  Secure  Xenix 

(M) 

The  access  matrix  M  of  the  system  state  is  interpreted 
in  Secure  Xenix  through  a  set  of  system  structures  main¬ 
tained  by  the  kernel.  The  system  structures  interpreted  for 
each  object  as  access  matrix  entries  are  either  access  con¬ 
trol  lists  (ACLs)  or  Xenix  (Unix)  specifications  but  not  both. 
These  structures  represent  the  storage  of  the  access  matrix 
by  columns.  That  is,  each  object  is  associated  with  a  list  of 
users  that  can  access  the  object,  each  user  having  a  set  of  ac¬ 
cess  privileges  restricting  his  access.  Access  control  lists  and 
Xenix  (Unix)  specifications  are  two  different  ways  of  storing 
the  access  matrix  by  column. 

An  ACL  is  a  set  of  <principai  identifier,  access 
privilcges>  pairs  that  is  attached  to  an  object.  The  principal 
identifier  is  a  non-reusable,  two  part  identifier  consisting  of  a 
user  identifier  and  a  group  identifier  (UID  and  CID).  The  user 
identifier  places  each  ii  dividual  user  in  a  separate  access  con¬ 
trol  group  by  himself,  uniquely.  The  group  identifier  places 
users  in  groups  whenever  such  users  are  relatec.  by,  or  cooper¬ 
ate  in,  some  activity  or  project.  Such  groups  imply  that  their 
members  have  similar  access  privileges  to  a  set  of  objects.  A 
user  may  belong  to  several  groups;  however,  at  login  time  he 
must  specify  the  group  in  which  he  wants  to  be  for  that  login 
session.  If  no  group  is  specified  at  login  time,  a  default  group 
is  assigned  to  the  user.  Both  group-membership  and  group- 
default  definition  on  a  per  user  basis  are  determined  by  the 
System  Security  Administrator  (SSA).  Default  group  speci- 
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fications  can  be  changed  by  the  SSA  at  the  user’s  request. 
Note  that  not  all  members  of  a  group  must  be  known  when 
the  group  is  formed.  Members  of  a  group  may  be  added  and 
deleted  by  the  SSA  subsequently. 

To  simplify  principal  identifiers,  a  DON’T  CARE  (i.e., 
“wild  card")  notation  has  been  added  (Saltier  74) .  A  DON'T 
CARE  in  a  user  or  a  group  field  of  a  principal  identifier 
is  denoted  by  an  asterisk  (*).  For  example,  the  identifier 
Jones.Networks.FSD  puts  a  user  Jones  in  the  Networks  JSD 
group.  By  contrast,  the  identifier  Jones.*,  names  a  user 
Jones  in  any  y roup,  whereas  the  identifier  .‘.Networks .FSD 
names  arty  user  in  the  Networks  JSD  group.  The  inclu¬ 
sion  and  exclusion  of  individual  users  on  ACLs  and  the 
review/revocation  of  privilege  mechanisms  arc  presented  in 
[Gligor  86). 

Both  ACLs  and  Xenix  protection  specifications  arc  as¬ 
sociated  in  a  one-to-one  correspondence  with  the  object  they 
protect.  For  example,  for  the  objects  that  have  file  system 
representation,  the  object  i-node  number  is  used  to  identify 
unambiguously  its  ACL.  The  ACL  is  destroyed  upon  object 
(and  i-node)  destruction.  For  objects  that  have  file  system 
representation  the  Xenix  protection  specifications  are  kept  in 
the  i-node  itself.  For  objects  that  do  not  have  file  system 
representation  (i.e.,  System  V  semaphores,  message  queues 
and  shared  memory  segments),  the  ACL  or  the  Xenix  protec¬ 
tion  specification  are  associated  with  the  object  through  the 
object’s  descriptor  (i.e.,  seuiid.ds,  msgid.ds,  and  shemidjds). 
For  example,  the  ACL's  i-node  number  is  stored  in  the  de¬ 
scriptor;  the  Xenix  specification  themselves  are  stored  di¬ 
rectly  in  those  descriptor  and  used  whenever  ACLs  are  not 
specified. 

3.1.6.  The  Security  Function  (F) 

The  definition  of  the  security  levels  as  binary  encodmgs, 
of  assignment  of  print  names  to  binary  encodings,  and  of  the 
(lattice)  relationships  between  security  levels  is  provided  in 
(Gligor  86].  In  this  section  we  focus  on  the  definition  of  the 
three  components  of  the  security  function,  namely,  the  assign¬ 
ment  of  maximum  security  level  (clearance)  to  each  subject, 
the  current  security  levels  (clearance)  of  each  subject,  and  the 
assignment  of  security  level  (classification)  to  each  object. 

The  assignment  of  user  clearances  in  Secure  Xenix  is 
performed  by  the  SSA  on  an  individual  and  group  basis  in 
the  user  security  profile  database.  The  individual  user  clear¬ 
ance  consists  of  a  User  Maximum  Level  (UML),  and  the 
group  cloarance  consists  of  a  Group  Maximum  Level  (GML). 
These  values  can  only  be  assigned  and  manipulated  by  the 
SSA,  and  must  be  in  the  range  System Jiigk  >  UML, 
GML  >  SysternJLow  for  the  System-High  and  System-Low 
values  defined  by  the  SSA.  The  subject  maximum  clearance  is 
the  greatest  lower  bound  (viz.,  (Gligor  86])  of  the  UML  and 
GML. 

The  current  subject  clearance  is  called  the  current  pro¬ 
cess  level  (CPL),  and  is  assigned  to  that  process  for  its  entire 
lifetime.  The  CPL  is  determined  at  process  creation  time  and 
must  be  between  the  process  maximum  level  (PML)  and  Sys¬ 
tem-Low.  The  PML  is  the  greatest  lower  bound  of  the  UML, 
the  GML,  and  the  terminal  maximum  level  (TML).  (Note 
that,  because  the  TML  is  no  greater  than  the  workstation 
maximum  level  (WML),  the  WML  is  never  lower  than  the 
PML.  The  TML  and  WML  are  discussed  below.)  The  CPL 
of  a  process  is  the  user  Requested  Jevcl  at  login  time,  or  the 


user  Default-level  if  no  level  is  requested,  if  and  only  if  the  Re- 
questedJevel/ Default  Jevel  is  less  than  or  equal  to  the  PML 
(or  equivalently  <  UML  and  <  GML  and  <  TML).  There¬ 
fore,  it  is  clear  that  the  subject  maximum  clearance  always 
dominates  the  current  subject  clearance  in  Secure  Xenix. 

Note  that  a  login  fault  is  detected  during  the  compu¬ 
tation  of  the  CPL  (and  PML).  The  fault  occurs  whenever 
the  terminal  minimum  level  (TmL)  is  greater  than  the  user 
maximum  level  (UML)  or  the  group  maximum  level  (GML). 
Consequently,  an  audit  record  is  written.  The  reason  for  this 
action  is  that  the  user  Is  likely  to  try  to  login  from  a  security 
area  where  he  does  not  belong.  Also  note  that  a  user  can 
always  request  a  level  that  is  lower  than  both  the  PML  and 
TmL,  so  long  as  both  that  user’s  GML  and  PML  are  no  lower 
than  the  TmL.  No  login  fault  occurs  in  this  case. 

The  assignment  of  object  classifications  consists  of  the 
assignment  of  ciarslucations  t.o  the  workstation  components 
and  the  assignment  of  classification  to  the  user-created  ob¬ 
jects.  The  assignment  of  classifications  to  workstation  com¬ 
ponents  is  performed  by  the  SSA  (during  the  definition  of 
workstation  security  profile),  whereas  the  assignment  of  clas¬ 
sifications  to  user-created  objects  is  done  by  the  Secure  Xenix 
kernel.  (The  current  level  of  the  workstation  devices  is  also 
assigned  by  the  kernel.) 

The  definition  of  the  workstation  security  profile  is  per¬ 
formed  by  the  system  security  administrator,  and  includes 
the  following  classification  ranges; 

(i)  The  individual  workstation  classification  range; 
i.e.,  workstation  maximum  security  level  (WML)  and  Sys¬ 
tem  -Low. 

(ii)  The  classification  range  of  each  individual  terminal 
and  private  devices  that  are  connected  to  each  workstation; 
i.e.,  terminal  maximum  and  minimum  level  (TML,  TmL)  and 
the  private  device  maximum  and  minimum  levels  (PDML, 
PDmL). 

The  assignment  of  these  values  to  a  specific  Secure  Xenix 
configuration  is  performed  by  the  SSA  and  depends  on  the 
operational  and  the  physical  security  environment.  For  exam¬ 
ple,  in  some  operational  environments  the  System-High  and 
System-Low,  and  all  other  security  levels,  may  have  the  same 
clearance  value  but  different  category  sets.  In  such  environ¬ 
ments,  the  security  levels  assigned  to  individual  workstations, 
devices  and  file  system  depend  solely  on  the  “need  to  know” 
basis. 

The  dependency  of  the  security  level  ranges  on  the  phys¬ 
ical  security  is  equally  important.  For  example,  the  work¬ 
stations  located  to  areas  accessible  to  users  cleared  at  low 
security  levels  have  a  lower  classification  than  that  assigned 
to  workstations  located  in  areas  whero  all  users  are  cleared  at 
the  highest  level.  Physical  security  considerations  may  also 
require  (1)  that  the  maximum  level  of  a  terminal  or  private 
device  be  lower  than  that  of  its  workstation  (TML/PDML 
<  WML),  and  (2)  that  the  minimum  level  of  a  terminal  be 
higher  than  System-Low  (TmL/PDmL  >  SL).  Terminals  and 
other  workstation  devices  may  be  located  in  a  different  phys¬ 
ical  security  area  than  that  of  its  workstation,  and,  thus,  the 
TML/PDML  may  be  lower  than  the  WML.  (Terminals  and 
other  private  devices  are  also  vulnerable  to  the  additional 
threat  of  spoofing,  and  thus  some  information  contained  in 
the  workstation  may  not  be  displayed  on  the  terminal  or  on 
the  private  device.) 
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A  user  can  only  change  the  level  of  a  private  device  or 
of  a  terminal  to  a  level  that  he  requests  at  login  time  (viz., 
the  computation  of  the  CPL).  The  current  level  of  a  private 
device  or  of  a  terminal  can  be  displayed  by  the  kernel  on  re¬ 
quest.  The  minimum  level  of  a  terminal  or  of  a  private  device 
classification  may  be  higher  than  System-Low  because  physi¬ 
cal  security  considerations  may  require  that  individuals  with 
a  low  clearance,  or  with  no  need  to  know,  may  be  denied 
access  to  workstations,  terminals  and  private  devices  located 
in  highly  classified  areas  or  in  areas  with  different  “need  to 
know*.  This  is  done  by  raising  the  TmL/PDmL  to  a  corre¬ 
spondingly  high  security  level. 

A  workstation  terminal,  or  a  private  device,  also  has  a 
current  classification,  called  the  Current  Terminal  Level,  or 
the  Current  Private  Device  Level  (CTL  or  CPDL).  In  Se¬ 
cure  Xenix,  both  the  CTL  and  CPDL  equal  the  CPL  of  the 
user,  system  process,  or  daemon  to  which  they  are  attached 
(and  that  owns  or  opens  them).  Note  that  it  is  possible  to 
have  CTL  <  TmL  because  CTL  =  CPL  and  CPL  equals  Re¬ 
quested  .Level  <  TmL  of  a  user  whose  UML,  GML  >  TmL. 
For  similar  reasons,  it  is  possible  to  have  CPDL  <  PDmL. 

The  determination  of  the  classifications  of  the  user- 
created  (or  opened)  objects  is  performed  by  the  Secure  Xenix 
kernel,  and  consists  of  the  following  three  groups  of  rules. 

(1)  Classification  of  Files,  Special  files, 

Xenix  Semaphores,  Xenix  Data  Segments,  and  ACLs 

Objects  in  this  group  have  a  single  level  for  their  entire 
lifetime.  (Exception  to  this  are  the  special  files  whose  ac¬ 
tivation  level  equals  the  level  of  the  process  that  activates 
or  opens  them.  None  of  the  Xenix  special  files  retain  any 
state  information  in  current  configuration.  Whenever  such 
files  retain  state  information,  SSA  intervention  is  required 
for  activation..)  That  is,  unless  a  special  trusted  process  with 
discretionary  access  to  that  object  changes  the  object  classi¬ 
fication  (i.e.,  downgrade  or  upgrade),  the  object  classification 
does  not  change.  The  classification  of  an  object  in  this  group 
is  the  CPL  of  the  creating  process  and  must  be  equal  to  the 
security  level  of  the  directory  containing  that  object. 

An  object  in  this  group  can  only  1  .?  destroyed  by  a  pro¬ 
cess  with  the  same  (CPL)  level  as  that  of  the  object;  the 
object  is  destroyed  only  if  its  reference  count  equals  zero  (i.e., 
it  is  not  shared  by  any  other  directory  or  process).  Note  that 
special  files  are  not  destroyed;  they  are  only  closed. 

(2)  Directory  Classification 

A  directory  has  a  single  security  level  for  its  entire  life¬ 
time,  just  as  in  the  case  or  ordinary  files.  However,  unlike 
ordinary  flies,  the  security  level  of  a  newly-created  directory 
can  bd  assigned  from  a  range  of  levels.  The  lowest  level  of  the 
range  is  the  CPL  of  the  creating  process  and  must  be  equal  to 
that  of  the  directory  that  contains  the  newly-created  direc¬ 
tory.  The  highest  level  of  the  range  is  the  WML.  If  a  process 
creates  a  new  directory  but  does  not  request  any  level  for 
that  directory,  the  default  level  of  the  directory  is  that  of  the 
process  (i.e.,  the  CPL)  and  that  of  the  containing  directory. 
The  classification  of  a  directory  does  not  change  during  the 
lifetime  of  the  directory  unless  a  trusted  process  with  discre¬ 
tionary  access  to  that  directory  always  changes  it. 

A  directory  can  only  be  destroyed  by  a  process  at  the 
same  level  (i.e.,  CPL)  as  that  of  the  containing  (parent)  di¬ 
rectory.  Also,  a  directory  can  only  be  destr  ved  if  it  contains 


no  files.  This  Xenix  interface  convention  introduces  a  covert 
channel,  which  is  discussed  in  [Giigor86]  because  a  lower  level 
process  can  discover  whether  a  higher  level  process  has  re¬ 
moved  all  the  files  from  the  higher  level  directory  when  it 
tries  to  remove  them. 

(3)  Classification  of  Processes,  System  V  Semaphores, 
Message  Queues  and  Shared  Memory  Segments 

The  security  levels  that  are  assigned  to  these  objects  by 
the  classification  rules  of  the  kernel  always  equal  the  CPL  of 
the  process  that  created  these  objects.  Similarly,  these  objects 
can  only  be  destroyed  by  the  process  that  created  them  or  by 
a  trusted  process  at  the  same  level  as  that  of  the  objects.  The 
classification  of  those  objects  does  not  change  during  their 
lifetime  unless  a  trusted  process  with  discretionary  access  to 
those  objects  changes  it. 

3.1.7.  Hierarchy  (H) 

The  only  Secure  Xenix  objects  that  may  contain  multi¬ 
ple  components  with  different  classifications  are  directories. 
Thus,  the  only  object  hierarchy  in  the  system  for  the  objects 
that  have  a  file  system  representation  is  that  provided  by  the 
directory  hierarchy.  All  objects  in  this  group  (i.e.,  group  (l) 
above)  are  classified  at  the  level  of  the  creating  process,  which 
must  equal  that  of  the  directory  containing  the  object. 

Objects  that  do  not  have  file  system  representation  (i.e., 
objects  in  group  (3)  above)  are  classified  at  the  level  of  their 
creator  process.  This  ensures  that  these  objects  cannot  be 
at  a  lower  level  than  that  of  the  processes’  current  directory. 
This  also  maintains  the  “nondecreasing  level”  rule  for  the 
directory  hierarchy.  These  objects  form  the  isolated  points 
(i.e.,  the  "stumps”  in  the  Bell-LaPadula  terminology  (Bell76j) 
of  the  hierarchy. 

The  rules  for  assigning  specific  classifications  to  directo¬ 
ries  in  the  hierarchy  prevent  a  process  from  placing  a  newly- 
created  directory  in  another  directory  at  a  lower  level  than 
that  process’  CPL.  However,  a  process  can  create  an  “up¬ 
graded”  directory  that  has  a  higher  level  than  that  of  the 
CPL  of  the  creating  process  and  that  of  its  containing  direc¬ 
tory. 

Note  that  a  user  process  can  create  links  in  its  current  di¬ 
rectory  to  objects  that  have  file  system  representation.  How¬ 
ever,  links  to  directories  can  only  be  created  by  trusted  pro¬ 
cesses.  User  processes  can  only  link  (non-directory)  objects 
in  the  process  current  directory  (i.e.,  CPL=directory  level), 
and  only  if  the  security  level  of  the  object  being  linked  equals 
that  of  the  current  directory. 

The  Secure  Xenix  hierarchy  has  a  ROOT  directory  whose 
level  is  always  SystemJow.  All  processes  have  the  search 
privilege  (x)  to  this  directory. 

3.2.  State  Transitions  in  Secure  Xenix 

Transitions  from  state  to  state  are  defined  by  the  kernel 
calls  and  returns  of  Secure  Xenix.  Thus,  each  rule  pi  in 
p :  RxV  ->DxV, 

of  the  Beli-LaPaduia  model  is  represented  as  follows: 

(1)  Each  request  Rk  €  R  is  represented  by  a  specific 
kernel  call  or  by  a  trusted  process  call  (these  calls  are  imple¬ 
mented  by  kernel  calls).  R  is  the  set  of  all  kernel  and  trusted 
process  calls. 

(2)  Each  input  to  Rk  comes  from  the  current  system  state 
V.  That  is,  both  parameters  explicitly  passed  to  each  call 
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(such  as  object  identifiers,  values,  pointers,  access  privileges, 
and  so  on)  and  parameters  implicitly  passed  to  each  call  (such 
as  the  system  hierarchy,  security  levels,  and  so  on)  belong  to 
the  current  system  state. 

(3)  Each  decision  Dm  €  D  =  {Yes,  No,  ?,  Error) 
is  represented  by  a  specific  return  to  a  kernel  call.  "Yes” 
is  represented  by  the  successful  return  parameter.  "No"  is 
represented  by  the  error  return  parameter  that  corresponds 
to  violations  of  the  access  control  (e.g.,  mandatory  or  discre¬ 
tionary  checks).  "?”  is  represented  by  the  error  return  pa¬ 
rameters  specifying  that  the  kernel  call  parameters  are  faulty 
(e.g.,  non-existent  file,  parameters  out  of  range,  attempt  to 
invoke  a  privileged  kernel  call,  etc.).  In  general,  these  er¬ 
ror  returns  are  called  domain  errors.  "Error"  is  represented 
by  error  returns  that  correspond  to  other  exceptional  con¬ 
ditions  detected  during  the  execution  of  specific  kernel  calls 
(e.g.,  deletion  attempted  on  a  non-empty  directory,  overflow 
conditions,  etc.).  Note  that  all  decisions  represent  some  in¬ 
formation  from  the  system  state  at  the  time  of  the  kernel  call, 
V,  or  from  the  new  system  state,  V*,  entered  by  the  system 
as  a  consequence  of  the  call. 

(4)  Whenever  Dm  ^  No,  Dm  ^  ?,  and  Dm  Error, 
the  output  of  Rk  includes  a  new  new  state  V*,  in  addition  to 
Dm=Yes.  The  new  system  state  may  include  new  objects,  a 
new  hierarchy,  or  may  exclude  some  objects  and  access  priv¬ 
ileges  from  previous  states,  and  so  on. 

The  Dm’ s,  the  characteristics  of  the  expected  and  of 
the  new  state  for  each  Rk  are  described  in  the  Secure  Xenix 
DTLSs. 

3.3.  Access  Control  in  Secure  Xenix 

In  this  section  we  report  the  invariant  access  control 
checks  that  are  performed  in  Secure  Xenix.  This  includes  the 
presentation  of  (l)  authorization  checks  for  mandatory  con¬ 
trol,  (2)  authorization  checks  for  discretionary  access  control, 
including  the  Setuid-Setgid  mechanism,  and  (3)  the  compu¬ 
tation  of  the  effective  access  authorization  to  objects. 

3.3.1.  Mandatory  Access  Authorization 

The  authorization  rules  are  divided  into  three  groups  de¬ 
pending  on  the  type  of  object  being  accessed. 

(1)  The  object  is  a  File,  a  Special  File  (Device),  a  Direc¬ 
tory  or  a  Shared  Memory  Segment  or  an  ACL: 

A  process  may  Read  (Execute)  an  object  if  the  CPL  of 
the  process  is  GREATER  THAN  or  EQUAL  TO  the  classifi¬ 
cation  of  the  object. 

A  process  may  Write  an  object  If  the  CPL  of  the  process 
is  EQUAL  TO  the  classification  of  the  object. 

This  rule  implies  that  the  data  displayed  on  a  private  de¬ 
vice  or  on  a  terminal  can  be  a  level  that  is  no  higher  than  that 
of  the  CPL  and,  implicitly,  of  the  CPDL/CTL.  Any  displayed 
data  that  may  have  to  be  at  a  lower  level  can  be  labeled  sep¬ 
arately  by  a  trusted  process  of  the  secure  application  itself. 
Thua,  the  application  is  responsible  for  providing  labels  for 
data  fields  that  would  be  appropriate  for,  and  that  use,  the 
different  terminal  features  (i.e.,  windowing,  scrolling,  etc.). 

(2)  The  object  is  a  Named  Pipe,  Semaphore,  Message 
Queue,  Xenix  Shared  Data  Segment: 


A  process  may  Read/ Write  (open/close)  an  object  if  the 
CPL  of  the  process  equals  the  classification  of  the  object. 

(3)  The  object  is  a  Process: 

A  process  can  signal  (kill)  another  process  if  the  CPL  of 
the  latter  is  GREATER  THAN  or  EQUAL  TO  that  of  the 
former. 

(4)  For  all  objects,  a  process  has  NULL  access  to  an 
object  if  the  CPL  of  the  process  is  ISOLATED  FROM  the 
classification  of  the  object. 

The  above  rules  imply  that  the  flow  of  information  in 
Secure  Xenix  can  only  take  place  from  a  given  level  to  another 
level  that  is  no  lower  than  the  first. 

The  mandatory  access  authorization  rules  presented 
above  are  invariant  for  all  Secure  Xenix  kernel  calls.  That 
is,  depending  on  whether  a  kernel  call  is  relevant  to  a  partic¬ 
ular  type  of  object,  one  or  several  of  the  above  rules  apply  to 
that  call.  These  rules  arc  compatible  with  the  os-property  and 
the  ‘-property  of  the  Bell-LaPadula  model  for  the  following 
reasons. 

(1)  Rules  1  and  2  of  Secure  Xenix  imply  conditions  (ii) 
and  (iii)  of  the  ‘-property. 

(2)  Rule  3  of  Secure  Xenix  implies  condition  (i)  of  the 
‘-property. 

(3)  Since  the  subject  maximum  clearance  (i.e.,  the 
greatest  lower  bound  of  UML  and  GML)  always 
dominates  the  current  subject  clearance  (i.e.,  CPL) 
in  Secure  Xenix,  Rules  1-3  above  imply  the  ss- 
property. 

However,  it  should  be  noted  that  equivalence  between  the 
ss-property,  the  ‘-property  of  the  Bcll-LaPadula  model  and 
any  system  interpretation  is  impossible  in  practice.  There  are 
two  reasons  for  this. 

First,  consider  the  meaning  of  the  execute  (e)  privilege  of 
the  Bell-LaPadula  model  presented  in  section  2.4  above.  This 
privilege  does  not  exist  in  practice  because,  in  any  system,  the 
execute  privilege  implies  some  observation  of  the  behavior  of 
the  object  being  executed.  Therefore,  in  practice,  the  execute 
(«)  privilege  must  be  eliminated  from  condition  (i)  of  the  ss- 
property  and  added  to  condition  (ii).  Furthermore,  it  must 
be  also  added  to  condition  (iii)  of  the  ‘-property;  otherwise, 
observation  of  objects  at  levels  that  are  higher  than  those 
allowed  to  the  user  or  his  process  is  possible. 

Second,  consider  the  implementation  of  the  “append” 
operation  that  requires  the  append  privilege  (a)  of  the  Bell- 
LaPadula  model,  In  practice,  append  operations  may  require 
one  or  more  of  the  following  observations  of  objects  or  system 
state: 

(1)  find  the  end  of  the  object  that  is  the  target  of  the 
append  operation; 

(2)  find  the  name  of  an  object  in  a  directory  at  a  higher 
level  than  that  of  the  process  executing  the  append 
operation; 

(3)  find  out  whether  the  object  exists; 

(4)  find  out  whether  the  append  operation  fails  due  to 
a  storage  channel  exception. 

Consequently,  in  practice,  the  append  operation  implies 
not  only  alteration  of  an  object  but  also  observation  of  the 
object  or  of  the  system  state.  Therefore,  in  practice,  the 
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append  (o)  privilege  must  be  eliminated  from  condition  (i)  of 
the  ss-property  and  added  to  condition  (ii)  of  the  *-propcrty 
for  the  similar  reasons  to  those  mentioned  for  execute  (e) 
above. 

With  the  above  two  modifications  that  are  required  in 
practice,  the  ss-property  and  the  ‘-property  would  be  equiv¬ 
alent  to  the  rules  1-3  of  the  Secure  Xenix  implementation. 
Note,  however,  that  consistency  of  the  Secure  Xenix  inter¬ 
pretation  with  the  model  only  requires  that  Rules  1-3  above 
imply  the  ss-property  and  the  ‘-property. 

3.3.2-  Discretionary  Access  Control 

The  discretionary  access  authorization  rules  of  Secure 
Xenix  define  the  Secure  Xenix  model  of  discretionary  policy. 
Discretionary  policy  is  characterized  by  four  classes  of  axioms, 
namely,  (1)  authorization  axioms,  (2)  axioms  for  distribution 
of  access  privileges,  (3)  axioms  for  review  of  access  privileges 
and  (4)  axioms  for  the  revocation  of  access  privileges.  The 
informal  specification  of  the  first  three  classes  of  axioms  are 
required  explicitly  by  the  [TCSEC  83]  in  the  discretionary 
access  control  area  of  B2-class  system.  The  informal  speci¬ 
fication  of  the  fourth  is  required  implicitly  in  the  statement 
that  “the  enforcement  mechanism  shall  allow  users  to  specify 
and  control  sharing  for  these  objects. 

(1)  Authorization  in  Secure  Xenix 

The  specification  of  the  discretionary  authorization 
mechanisms  of  any  system  consists  of  two  parts.  First,  it 
must  include  a  specification  that  relates  every  (kernel)  oper¬ 
ation  on  one  or  more  objects  with  the  privileges  required  by 
the  operation  for  those  objects.  This  is  necessary  because  the 
authorization  mechanism  requires  different  (combinations  of) 
privileges  for  different  operations.  Lack  of  such  specification 
could  mean  that  the  wrong  privilege  may  authorize  an  op¬ 
eration.  As  seen  in  section  3.1.3  above,  the  correspondence 
between  an  access  privilege  to  a  kernel  operation  depends  on 
the  type  of  objects  and  is  not  entirely  obvious. 

Second,  the  discretionary  authorization  mechanisms 
must  include  a  specification  of  how  the  current  access  privi¬ 
leges  of  subjects  are  related  to  the  specification  of  the  subjects 
access  to  objects  by  the  access  matrix.  This  relationship  is 
defined  by  the  ds-property  of  the  Bell-LaPadula  model,  and  is 
important  because  it  relates  the  high-level,  human-oriented, 
discretionary  access  controls  specified  by  the  access  matrix 
with  low-level,  human-oriented,  discretionary  access  controls 
specified  by  the  access  matrix  with  the  low-level,  system- 
oriented,  discretionary  controls  of  the  system. 

It  should  be  noted  that  the  requests  Rk  discussed  below, 
namely,  CALL,  REVOKE,  REVIEW,  ACCESS,  GRANT, 
EXCLUDE  are  implemented  by  kernel  calls  or  sequences  of 
kernel  calls  that  require  the  reading  and  writing  the  ACL  and 
Xenix  specifications.  ACCESS  and  CALL  are  implemented 
by  a  single  kernel  call  (i.e.,  “access"  and  “exec”). 

The  two  general  requirements  of  discretionary  autho¬ 
rization  can  be  expressed  by  the  following  two  axioms.  Let 
P  :  R  x  V  — ♦  D  x  V'  be  the  set  of  rules. 

For  all  Rk  executed  by  Si  on  some  objects  Oj  with 
Rk  #  CALL,  GRANT,  REVOKE,  REVIEW,  ACCESS,  EX¬ 
CLUDE,  and  x  are  the  required  access  privileges  for  Rk 

(1.1)  {Dm  —  YES)  =f>  (S,-,  Oj,x)  €  B,  and 

(1.2)  {Sit  Oj,  x)  e  B  =>  x  £  [Bell-LaPadula 
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Secure  Xenix  satisfies  both  requirements  mentioned 
above.  First,  the  DTLSs  of  Secure  Xenix  specify  the  dis¬ 
cretionary  privileges  for  each  type  of  object  that  are  required 
by  each  kernel  call.  Furthermore,  the  kernel  call  fail  whenever 
the  required  privileges  are  not  among  the  privileges  of  each 
object  used  by  the  call.  Second,  each  current  access  of  a  pro¬ 
cess  to  an  object  is  derived  from  either  the  objects’  ACL  or 
from  its  Xenix  specifications  (i.e.,  i-node,  semid-ds,  msgid-ds, 
shemid-ds)  when  the  object  is  open  or  created;  viz.,  section 
3.1.4  above.  Because  these  data  structures  represent  the  ac¬ 
cess  matrix  in  Secure  Xenix  (viz.,  section  3.1.5  above),  the 
ds-property  of  the  Bell-LaPadula  model  is  also  satisfied. 

(B)  Distribution  of  Aecess  Privileges  in  Secure  Xenix 

The  policy  for  the  distribution  of  access  privileges  must 
specify  how  “the  access  permission  to  an  object  by  users  not 
already  possessing  access  permission  shall  only  be  assigned 
by  authorized  users"  jTCSEC  83). 

In  Secure  Xenix,  the  only  users  that  are  authorized  to 
distribute  object  privileges  to  other  users  are  the  owner  of 
those  objects.  Ownership  of  an  object  is  a  user  attribute  and 
not  an  access  privilege.  In  Xenix,  ownership  is  determined 
solely  by  the  user  identifier  (and  not  by  the  group  identifier 
GID).  Each  object  has  only  one  owner  and  only  the  owner  is 
authorized  to  modify  either  the  ACL  or  the  Xenix  specifica¬ 
tions  for  his  objects. 

This  privilege  distribution  policy  is  succinctly  stated  by 
the  following  two  axioms: 

(2.1)  Ownership  Axioms: 

Vi  j,  \/SitSj  £  S',  Si  =  Owner{Oi)  => 

Sj  Oiuner(Ot),  and 

Si  =  Owncr{Oi)  =>  Vz  6  A,x  £  Mu 

(2.2)  Privilege  Granting  Axiom: 

Let  p  :  R  x  V  — >  D  X  V*  be  the  set  of  rules. 

For  all  Rk  executed  by  S,  on  objects  Oj  with 
Rk  =  GRANT{x,  Sf) 

{Dm  =  YES)  (S,-  =  Owner{Oj)\  and 
£  £  Mpj 

The  effects  of  the  privilege  granting  are  equivalent  to  the 
inclusion  of  a  user/group  identifier  on  an  ACL  or  in  the  Xenix 
specifications.  The  inclusion  of  users  on  ACL’s  is  explained  in 
section  3.1.5  above  and  on  Xenix  specifications  for  an  object 
in  [Ritchie  74]. 

Similarly,  the  policy  for  the  distribution  of  access  privi¬ 
leges  must  be  able  “to  specify  a  list  of  named  individuals  and 
a  list  of  groups  of  named  individuals  for  which  no  access  to 
the  object  is  to  be  given” . 

In  Secure  Xenix  this  is  possible  since  the  owner  can  either 
decide  not  to  include  a  specific  user  or  group  in  the  ACL  or 
Xenix  access  specification  or  to  exclude  a  specific  user’s  or 
group’s  access  as  explained  in  section  3.1.5  above. 

(2.3)  Privilege  Exclusion  Axiom: 

Let  p  :  R  x  V  — ►  D  x  V‘  be  the  set  of 
rules.  For  all  Rk  executed  by  Si  on  M[5,-,0<]  with 
Rk  =  EXCLUDERS,},  0{) 

{Dm  =  YES)  =4-  [V;  f-  i,  Si  =  Owntr{Oi) 
and  ( Sj,0i,4> )  £  B,  where  {Sy}  C  S'], 
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($)  Review  of  Access  Privileges  in  Secure  Xenix 

The  policy  for  review  of  access  privileges  “shall  be  ca¬ 
pable  of  specifying,  for  each  named  object,  a  list  of  named 
individuals  and  a  list  of  groups  of  named  individuals  with 
their  respective  models  of  access  to  that  object”  [TCSEC  83). 

In  Secure  Xenix,  the  only  users  that  can  perform  access 
review  (i.e.,  reading  the  ACL  or  the  Xenix  specifications)  for 
an  object  are  the  owners  of  that  object.  However,  any  user 
can  inquire  whether  he  has  access  to  an  object,  and  what  type 
of  access,  regardless  of  the  object’s  ownership. 

This  can  be  succintly  stated  by  the  following  axioms.  Let 
p  :  R  X  V  — ►  D  X  V*  be  the  set  of  rules. 

(3.1)  For  all  Rk  executed  by  Si  on  M [S„  Oj\  with  Rk  = 
REVIEW(Oy): 

( Dm  =  YES)  =>  Si  — •  Owner(Oj) 

(3.2)  For  all  Rk  executed  by  Si  on  Oj  with  Rk  = 

ACCESS(Oy): 

{Dm  =  YES)  =►  Si  £  S\ 

(i)  Revocation  of  Privileges  in  Secure  Xenix 

The  policy  for  revocation  of  privilege  must  specify  how 
access  privileges  for  an  object  can  be  taken  away  from  users 
that  have  these  privileges  in  a  selective  manner  and,  possibly, 
partially. 

In  Secure  Xenix  the  (selective  and  partial)  revocation  of 
access  privilege  can  be  performed  only  by  the  owner  of  an  ob¬ 
ject.  The  reason  is  that  only  the  owner  of  the  object  may  mod¬ 
ify  AOLs  and  Xenix  specifications.  This  can  be  expressed  suc¬ 
cinctly  by  the  following  axiom.  Let  p  :  R  x  V  — ►  D  x  V* 
be  the  set  of  rules. 

(4.1)  For  all  Rk  executed  by  Si  on  Af[S,-,Oj]  with 
Rk  =  REVOKE(*,5p)  : 

{Dm  =  YES)  =>  [V*  /  p,  x  ?  Mpj 
and  Si  =  Owner(Oj )] 

(S)  The  Sctuid-Setgid  Mechanism  of  Secure  Xenix 

The  SETUID  protection  mode  is  used  to  build  controlled 
interfaces  to  various  objects  (Ritchie  74).  Whenever  a  pro¬ 
gram  with  the  SETUID  bit  is  executed,  the  invoking  process 
inherits  the  privileges  of  the  program  owner.  Every  process 
has  both  a  real  and  an  effective  user  identifier  that  are  iden¬ 
tical  except  when  a  SETUID  program  is  executed.  Then  the 
effective  user  Identifier  is  set  to  that  of  the  program  owner. 
All  discretionary  access  control  decisions  are  based  on  the  ef¬ 
fective  user  identifier  and  not  on  the  real  one.  (There  is  a 
similar  mechanism  called  the  SETUID  mechanism  for  chang¬ 
ing  the  effective  group  identifier.) 

Although  the  SETUID  feature  can  be  very  useful  it  also 
poses  three  types  of  security  risks:  first,  a  poorly  designed 
SETUID  program  can  compromise  the  program  owner’s  se¬ 
curity;  second,  the  code  of  'he  SETUID  program  may  be 
modified  in  an  unauthorized  way;  third,  a  Trojan  Horse  in  a 
borrowed  program  may  steal  a  user’s  privileges  by  creating  a 
SETUID  program. 

The  modifications  to  the  SETUID/GID  mechanism  pre¬ 
sented  in  (Gligor  86]  make  it  impossible  for  a  user  to  change 
an  existing  SETUID  program,  or  for  a  Trojan  Horse  to  steal 
user’s  privileges  by  creating  a  SETUID  program.  However, 
It  is  the  responsibility  of  the  user  to  use  extreme  care  in  the 
design  of  SETUID  programs.  The  operating  system  cannot 


protect  the  user  from  his  own  mistakes.  Even  if  the  user  is 
careless  or  malicious,  he  can  only  hurt  himself  by  misusing 
the  modified  SETUID  features  mentionetj  above  because  he 
cannot  create  a  SETUID  program  under  a  different  user’s 
identifier.  Note  that  the  mandatory  access  control  (discussed 
below)  remains  unaffected  by  the  SETUID  mechanism. 

The  SETUID/GID  mechanism  of  Secure  Xenix  enforces 
the  separation  of  privileges  between  the  subject  that  invokes 
a  SETUID/GID  program  and  the  subject  that  owns  the  pro¬ 
gram.  This  means  that  a  subject  invoking  a  SETUID/GID 
program  may  only  have  indirect  access  to  some  of  the  objects 
of  the  SETUID/GID  program  owner.  This  can  be  expressed 
succinctly  by  the  following  axiom: 

(5.1)  Let  A  -  {r,  to,  x,  null,  suid-gid } 
[S;,Oy,tndiVeei(x)]  £  B  =>- 
CALL{Sj, Ok),  S{  =  Owner{Ok), 
suid^id  e  Mik  and  (5«,0,-,x)  £  B 

In  other  words,  if  a  program  has  the  SETU1D-GID  bit 
on,  the  subject  Si  executing  it  has  privileges  of  the  owner  to 
objects  Oi  that  may  not  be  directly  available  to  that  subject’s 
callers  (i.e.,  S-). 

3.3.3.  Computation  of  the  Effective  Access  in  Se¬ 
cure  Xenix 

The  effective  current  access  of  a  subject  to  an  object  in 
Secure  Xenix  follows  two  rules.  These  rules  are  compatible 
with  the  Bell-LaPadula  model.  They  are: 

(1)  A  user  process  is  allowed  to  access  an  object  In  a 
given  mode  (i.e.,  requiring  a  certain  privilege)  only  if  both 
mandatory  and  discretionary  checks  are  passed. 

(2)  The  Error  value  returned  for  failed  discretionary 
checks  must  be  the  same  as  that  returned  from  failed  manda¬ 
tory  checks  unless  the  mandatory  checks  have  passed. 

The  first  rule  is  necessary  because,  otherwise,  the  re¬ 
quirement  of  the  secure  states  and  the  Basic  Security  The¬ 
orem  of  the  Bell-LaPadula  model  would  be  violated.  The 
second  rule  is  necessary  because  otherwise  leakage  of  infor¬ 
mation  from  higher  levels  to  lower  levels  may  be  possible. 
That  is,  whenever  the  discretionary  checks  are  done  first,  a 
higher  level  subject  may  revoke  or  add  a  privilege  for  an  ob¬ 
ject  to  a  lower  level  subject.  The  lower  level  subject  would 
then  distinguish  between  denied  discretionary  access  and  de¬ 
nied  mandatory  access  errors.  Thus,  by  modulating  the  dis¬ 
cretionary  access  of  the  lower  level  subject  to  a  higher  level 
obj'set,  a  higher  level  subject  could  transfer  information  to 
a  lower  level  object.  In  Secure  Xenix,  the  mandatory  access 
checks  be  performed  before  the  discretionary  checks  for  every 
kernel  call  accessible  to  a  user  process.  However,  this  is  a 
stronger  requirement  than  the  more  general  one  specified  in 
(2)  above. 

3.4.  Initial  State  (20) 

The  initial  state  of  any  Secure  Xenix  installation  is  set 
by  a  secure  initialization  procedure.  The  secure  initialization 
consists  of  three  distinct  phases:  (1)  system  configuration 
and  generation,  (2)  system  and  user  security  profile  defini¬ 
tion,  (3)  normal  startup  (or  Initial  Program  Load  -  IPL).  The 
first  phase  is  performed  by  the  TSP  (Trusted  Systems  Pro¬ 
grammer)  in  maintenance  mode.  Once  this  mode  is  left,  the 
TSP  functions  are  automatically  disabled,  and  only  the  rest 
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of  the  administrative  users  have  access  to  the  workstation. 
The  second  phase  work  is  performed  by  the  SSA.  The  third 
phase  work,  normally  the  IPL,  is  performed  by  anybody  with 
physical  access  to  the  power  on/off  switch  of  the  workstation. 

The  IPL  of  the  Secure  Xenix  can  only  take  place  with 
input  from  the  fixed  disk,  whereas  in  maintenance  mode,  the 
IPL  can  only  take  place  with  input-  from  the  removable  media 
(e.g.,  diskette)  drive.  This  separation  of  IPL  input  is  enforced 
by  a  special  hardware  configuration  that,  when  installed  by 
the  TSP,  prevents  user  mode  IPL  from  using  the  removable 
media  drive.  No  cryptographic  authentication  of  the  remov¬ 
able  medium  [Gligor  79)  is  performed  at  this  time.  The  TSP 
is  the  only  administrative  user  that  has  access  to  the  internal 
hardware  configuration,  and  he  would  have  to  be  trusted  to 
configure  the  system  correctly  anyway.  (If  the  TSP  is  not 
trusted,  on-site  physical  surveillance  methods  would  become 
necessary,  cryptographic  authentication  notwithstanding) . 

During  the  Secure  Xenix  IPL,  several  consistency  checks 
are  performed.  Xenix  already  performs  file  system  consis¬ 
tency  checks  (i.e.,  through  the  “fsck"  program).  In  particular, 
the  IPL  recovers  whenever  the  system  is  started  up  after  an 
improper  shut-down  (i.e.,  after  a  crash,  after  power-off  during 
disk  I/Os,  etc.)  This  ensures  that  security  label  consistency 
is  maintained  because  cacti  label  is  written  onto  the  disk  with 
a  separate,  atomic  sector-write  operation.  In  addition  to  the 
file  system  consistency  checks,  Secure  Xenix  checks  (1)  tiie 
consistency  of  the  security  map,  (2)  the  consistency  of  the 
current  obje-t  label,  and  (3)  the  consistency  of  the  overall  se¬ 
curity  level  hierarchy  (i.e.,  the  non-decreasing  security  levels 
for  directories).  This  is  done  by  the  “scheck”  program. 

3.5.  Compatibility  in  Secure  Xenix 

The  interpretation  of  the  compatibility  axiom  in  Secure 
Xenix  requires  that  a  directory  contains  (l)  non-directory  ob¬ 
jects  (which  have  file  system  representation)  only  at  the  same 
level  as  that  of  the  directory,  and  (2)  directory  objects  at  the 
some  level  as  that  of  the  directory  or  higher.  Consequently,  if 
a  directory  is  at  a  higher  security  level  than  that  of  a  subject, 
all  objects  filed  in  that  directory  remain  inaccessible  to  the 
subject. 

The  rules  for  object  classification  discussed  in  section 
3.1.6  above,  and  the  definition  of  the  Secure  Xenix  hierarchy 
discussed  in  section  3.1.7  above,  imply  that  the  compatibility 
axiom  is  satisfied. 

3.6.  Tranquility  in  Secure  Xenix 

The  section  3.1.6  is  specified  that  both  the  current  pro¬ 
cess  level  (clearance)  and  the  classification  of  objects  in  Secure 
Xenix  do  not  change  during  the  lifetime  process  and  of  an  ob¬ 
ject,  respectively  (unless  a  trusted  process  with  discretionary 
access  to  those  objects  or  with  root  privileges  changes  those 
levels).  This  suggests  that  the  kernel  call  accesses,  and  the 
clearance  and  classification  rules  of  Secure  Xenix  satisfy  the 
tranquility  principle  of  the  Bell-LaPadula  model. 

3.7.  Activation 

The  design  of  Secure  Xenix  satisfies  the  two  activation 
axioms  defined  in  section  2.4.6  above.  First,  an  active  object 
can  become  inactive  only  through  destruction.  Objects  that 
have  file  system  representation  are  inactivated  by  the  destruc¬ 
tion  of  their  i-nodes  and  by  the  deallocation  of  the  appropri¬ 
ate  table  entries  (i.e.,  file  descriptor,  file  table  entry).  Objects 


that  do  not  have  file  system  representation  are  inactivated  by 
the  destruction  of  their  descriptors  and  of  their  table  entries 
(i.e.,  shared  memory,  semaphore  and  message  queue  table  en¬ 
tries).  A  process  is  destroyed  by  destroying  the  corresponding 
process  table  entry.  Consequently,  the  destruction  of  all  these 
objects  makes  them  inaccessible  to  any  active  process. 

Second,  whenever  an  object  is  created  (activated)  the 
state  of  the  object  is  automatically  written  by  the  kernel  with 
zeros.  Thus,  the  previous  states  of  this  object,  or  of  any  other 
destroyed  object  whose  storage  representation  is  being  reused, 
are  erased  before  reuse.  This  is  discussed  in  more  detail  in  a 
separate  document  on  object  reuse.  Thus,  the  state  of  a  newly 
activated  object  cannot  depend  on  the  state  of  any  previous 
object  incarnation. 

Note  that  the  destruction  (inactivation)  of  some  objects, 
such  as  some  special  files  representing  terminals,  do  not  cause 
the  object  representation  to  be  “erased."  Whenever  such  ob¬ 
jects  do  not  retain  state  information  they  can  be  reactivated 
and  made  accessible  to  different  processes  (and  labeled  ac¬ 
cordingly;  viz.  section  3.1.6  above).  However,  the  activation 
of  objects  that  retain  state  information  after  their  deactiva¬ 
tion  requires  the  intervention  of  the  SSA  and  of  trusted  pro¬ 
cesses  (i.e.,  mount/unmount  volumes). 

Secure  Xenix  also  satisfies  an  additional  activation  axiom 
that  define  the  classification  of  a  newly  activated  (created) 
object  and  the  object  destruction  rule. 

Consistency  with  the  compatibility  axiom  and  with  the 
“-property  requires: 

(3)  Classification  of  Newly  Activated  Objects  and  the  Ob¬ 
ject  Destruction  Rule 

Let  O  =•  O'  U  O",  where  0'(0")  =  active  (inactive)  ob¬ 
jects,  and 

ncw(o)  =  {O'  :=  O"  —  o  and  O'  :=  O'  +  o),  and 

destroy(o)  -  {O'  :=  O'  -  o  and  O"  :=  O"  -f  o) 

(CALL[S»,  new(o)]  or  CALL[S\,  dcslroy(o)]}  =*• 

{//-»  #  <t>  =>  fo{o)  >  /.(Si)  =  /o[tf-‘(o)]  or 
=$&=■>  f0[o)  =  fc{Si)} 

where  II~l(o)  is  the  parent  of  object  o. 

The  interpretation  of  these  axioms  in  Secure  Xenix  is  dis¬ 
cussed  in  section  3.1.6  above. 

4.  Conclusion 

In  this  paper  we  have  reviewed  the  Bell-LaPadula  model 
for  secure  systems  in  its  most  complete  form.  Wo  also  defined 
the  interpretation  of  this  model  in  Secure  Xenix  has  been 
defined.  We  showed  that  the  access  control  mechanisms  of 
Secure  Xenix  satisfy  the  axioms  of  the  Bell-LaPadula  model. 
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INFORMAL  VERIFICATION  ANALYSIS 


By  Barry  C.  Stauffer  and  Roger  U.  Fujii 
Logicon,  Inc. 


The  concern  for  the  security  of  ccnputer  systems  has 
been  intensified  by  the  increasing  dependency  of  the 
system  on  the  computers  and  the  ability  for  the 
systems  to  react  autonomously.  The  development  of 
secure  systems  has  proven  to  be  an  engineering 
challenge.  While  much  emphasis  has  been  devoted  to 
perfection  of  formal,  specification  techniques,  to  date 
these  techniques  have  had  only  limited  use  in 
fielding  state-of-the-art  systems.  The  need  for 
assurance  of  secure  systems  remains. 

This  paper  presents  an  adaption  of  existing  software 
verification  and  validation  technology'  to  be  applied 
to  the  specific  needs  of  caiputer  security. 


1.  Introduction 

Computer  security  includes  all  measures  to  protect 
against  unauthorized  (accidental  or  intentional) 
disclosure,  moditication,  or  destruction  of  computer 
systems,  processes,  and  data.  Also  included  are 
those  measures  to  protect  against  denial  of  service. 

Of  concern  is  the  protection  of  classified  data, 
mission  critical  data  and  processes,  unclassified  data 
requiring  special  protection  (official,  use  only  data, 
personnel  data,  etc.)  and  integrity  of  data.  Mission 
Critical  Computer  Systems  (MCCS)  have  the  additional 
concerns  of  process  security  and  process  integrity, 
i.e. ,  to  provide  assurance  that  one  process  cannot 
inadvertently  access,  initiate  or  deny  access  to 
another  critical  process. 

We  have  gained  an  increased  understanding  of  security- 
specific  technical  issues  from  the  oanputer  security 
work  undertaken  over  the  last  decade.  Two  significant 
developmental  factors  affect  the  security  of  computer 
systems.  The  first  is  the  rigorous  use  of  sound 
modem  software  engineering  principles  oanbinad  with 
systematic  detailed  program  reviews.  The  second 
factor  is  evaluating  and  incorporating  critical 
security  issues  during  all  phases  of  the  development 
cycle  (i.e,  build  computer  security  into  the  system 
rather  than  add  it  as  a  separate  part) . 

The  use  of  a  security  model  is  the  most  effective  way 
to  evaluate  critical  security  issues.  As  part,  of  the 
system  requirements,  a  system  security  model  defines 
the  system-enforced  security  rules. 

It  specifies  the  access  controls  on  the  use  of 
information  and  hew  information  will  be  allowed  to 
flew  in  the  system.  The  model  also  provides  the 
mechanism  for  specifying  how  to  change  access  controls 
and  interfaces  dynamically  without  compromising  system 
security.  A  precisely  tailored  security  model  can 
ensure  that  a  system  will  contain  a  level  of  security 
appropriate  to  its  intended  application.  Thus  the 
security  model,  which  defines  system  security  needs, 
is  a  major  component  of  a  secure  system. 

The  major  remaining  factor  in  tlie  development  of 
secure  computer  systems  is  the  ability  to  validate 
secure  system  behavior.  Complete  and  total  trust  in 
the  security  of  system  can  only  be  achieved  with  a 
formal,  mathematically  sound  validation  that  the 
system,  as  built,  correctly  implements  its  formally 
specified  security  model.  The  theory  of  formal 


program  validation  is  new  better  understood,  except 
for  problems  of  concurrency  and  asynchronism,  and  a 
significant  amount  of  progress  has  bean  made  toward 
verifying  the  correctness  of  ccmputer  programs  with 
complete  mathematical  integrity.  At  the  present  time, 
this  teclmology  can  only  be  used  to  validate  small 
programs.  The  time  and  cost  to  validate  a  large 
complete  program,  such  as  an  operating  system, 
precludes  the  use  of  this  formal  validation  technology. 
There  is,  however,  a  rigorous,  though  less 
mathematically  fomal,  technology  that  can  be  used  to 
validate  system  security. 

2.  Independent  Verification  and  Validation 

Independent  Verification  and  Validation  (IV&V)  is  the 
systematic  analysis,  test  and  evaluation  of  a  computer 
system  by  a  contractor  or  agency  independent  of  the 
developer.  It  is  a  highly  structured,  rigorous 
system  engineering  discipline  consisting  of  a  series 
of  specific  activities  which,  in  the  ideal,  parallel 
program  development.  Its  goal  is  to  provide  complete 
and  total  assurance  that  the  delivered  operational 
system  satisfies  all  of  its  requirements  and  is 
limited  to  performing  only  its  intended  functions. 

IEEE-STD-729  defines  Verification  and  Validation  ass 

“T)ie  process  of  determining  whether  or  not  the 
products  of  a  given  phaso  of  the  software 
development  cycle  fulfill  the  requirements 
established  during  the  previous  phase,"  and 
“The  process  of  evaluating  software  at  the  end 
of  the  software  development  process  to  ensure 
compliance  with  software  requirements." 

Figure  1  is  a  graphic  depiction  of  the  IV&V  process. 


IV&V  was  developed  in  the  1960s  for  several  military 
and  space  programs  with  a  clear  need  to  ensure  the 
reliability  of  critical  software.  Since  its  inception, 
the  IV&V  methodology  has  been  expanded  to  include  the 
analysis  of  the  entire  system.  TV&V  has  been 
performed  on  varied  MXS  including  missile  control, 
launch,  guidance  and  maintenance  software;  avionics 
software;  missile  mission  planning,  weapons  control, 
and  flight  software;  satellite  ground  and  flight 
systems;  C3  intelligence  systems. 

The  starting  point  for  IV&V  methodology  is  a 
criticality  analysis  which  focuses  IV&V  resources  on 
those  software  functions  which  are  deemed  system 
critical.  This  effort  is  independent  of  specific 
IV&V  tasking  and  is  used  to  define  the  nature  said 
scope  of  IV&V  for  specific  systems.  Criticality 
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analysis  of  nuclear  missile  systems,  for  exanple,  has 
resulted  in  an  XV&V  technology  kncwn  as  Nuclear 
Safety  Cross  Check  Analysis  (NSOCA) .  NSOCA  focuses  on 
system  critical  nuclear  safety  issues,  including 
prevention  of  unauthorized  or  inadvertent  arming, 
enabling,  launching,  firing,  or  releasing  of  the 
weapon  system?  prevention  of  a  faulty  launch?  and 
premature  or  unsafe  operation  of  the  weapon  system, 
among  other  possibilities.  This  technology  has  been 
formalized  in  the  Air  Force  AFR-122  regulations  and  is 
also  being  adapted  in  a  Navy  standard  for  Software 
Nuclear  Safety  (MID-STD-SNS) , 

3.  Computer  Security  Evaluation 

IV&V  and  NSOCA  technology  have  been  adapted  to  meet  the 
specific  needs  of  caiputer  security.  The  analysis, 
called  Computer  Security  Cross  Check  Analysis  (CSOCA) 
focuses  on  the  critical  computer  security  issues. 

CSCCA  starts  with  the  critical  security  objectives 
analysis  to  focus  the  effort  on  the  security  critical 
functions  of  a  specific  system.  For  example,  on  an 
intelligence  collection  and  dissemination  system  these 
objectives  would  verify  the  developed  software  does 
not  permit: 

-  unauthorized  or  inadvertent  access  of  processes, 
fixing  algorithms,  sources,  or  gathered  data 

-  deliberate  or  inadvertent  denial  of  system 
services 

-  unauthorized  use  of  system  services 

-  deliberate  or  inadvertent  misuse  of  system 
services 


Computer  security  cross  check  analysis  contains  a 
series  of  activities  to  analyze  and  test  the  products 
of  the  development  process.  These  activities  are 
designed  to  detect  as  early  as  possible  those 
development  problems  which  affect  security  issues  and 
to  provide  the  program  manager  with  increased 
visibility  into  the  security  requirements  of  the  system 
under  development.  These  activities  include: 

-  System  security  requirement-  3  analysis 

-  Design  analysis 

-  Code  analysis 

-  . Independent  security  testing 

-  System  validation  and  recarmendation  for 
certification 

The  process  begins  with  a  thorough  analysis  and 
evaluation  of  the  security  requirements  for  the  system. 
'Hie  purpxose  of  this  analysis  is  two-fold.  First;,  to 
independently  derive  from  the  security  instructions 
those  security  requirements  that  apply  to  the  Systran. 
Second,  to  tailor  the  analysis  approach  to  the  specific 
needs  of  the  system  under  evaluation.  For  maximum 
benefit.,  the  analysis  and  evaluation  oi;  the  system 
security  requirements  should  be  performed  early  in  toe 
program  development  cycle  so  that  potentially 
conflicting  or  inconsisb  >nt  system  requirements  are 
detected  and  corrected  before  toe  requirements  are 
translated  into  program  design  code .  Figure  2 
demonstrates  this  analysis. 

'.the  objective  of  requirements  analysis  i.s  to  ensure 
that  the  system  functional  requirements,  as  embodied 
in  the  requirements  documentation,  aro  consistent  with 
toe  system  security  requirements .  Requirements 
analysis  detects  errors  and  deficiencies  in  the 
requirements  which  could  result  in  a  subsequent  system 
failure  to  meet  the  critical  security  objectives. 

The  analysis.  Figure  3,  evaluates  the  program 
requirements ,  interface  requirements,  access 
requirements,  control  flaw  requirements,  timing  and 
sizing  requirements,  etc.,  for  compliance  with  the 
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security  model.  Requirements  analysis  also  ensures 
that  system  requirements  are  properly  implemented  in 
the  security  kernel,  if  appropriate. 

The  objective  of  design  analysis  is  to  verify  the 
system  design  is  OMisiscent  with  the  system  security 
requirements,  i.e.,  the  requirements  are  traced  into 
toe  design.  Design  analysis,  Figure  4,  evaluates  the 
system  design  for  compliance  with  the  security  model 
and  detects  errors  and  deficiencies  in  the  design. 

Design  analysis  evaluates  the  data  flew,  process 
interfaces,  and  overall  control  logic  of  the  design  in 
terms  of  its  ability  to  implement  the  security 
requirements.  The  design  of  access  controls  and 
information  flows  are  evaluated  for  correctness  and 
consistency  with  security  requirements.  Design 
analysis  evaluates  the  description,  security  level,  and 
intended  usage  of  each  data  item  in  the  program  design 
to  verify  that  the  structure,  security  level,  and 
intended  usage  of  program  data  will  satisfy  the  security 
requirements. 

Design  data  analysis  also  evaluates  the  relationships 
between  secure  processes  and  ensures  that  those 
relationships  satisfy  the  security  requirements.  The 
design  of  interfaces  between  program  components, 
firmware,  aid  hardware  is  analyzed  making  certain  tiiat 
these  interfaces  have  been  correctly  defined  and  do 
not  violate  security  requirements.  The  design  is 
correlated  to  the  system  requirements  to  make  certain 
too  design  is  a  correct  and  ccwplete  .Implementation 
of  the  system  requirements. 
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Kernel  analysis  evaluation  is  a  critical  part  of  the 
design  analysis  since  a  kernel  mediates  all  accesses 
to  system  resources  and  therefore,  inplements  the 
basic  security  rules  for  the  system.  Design  analysis 
must  include  evaluation  of  the  correctness  and 
completeness  of  tlia  mediation  process  with  respect  to 
the  security  policy  requirements.  Hie  kernel  design 
must  be  carefully  examined  to  determine  that  a  tamper¬ 
proof  implementation  is  feasible.  For  verification 
purposes,  the  kernel  functions  nust  be  kept  to  a 
minimum.  Hie  design  must  be  evaluated  to  determine 
that  only  those  functions  essential  for  the  most 
critical  security  rules  are  expressed  in  the  kernel. 
While  it;  is  most  desirable  to  minimize  kernel 
functions,  some  designs  may  include  trusted  processes 
within  the  security  kernel.  Trusted  processes  may  be 
permitted  to  bypass  certain  security  rules,  for  example, 
allowing  downgrading  for1  a  specific  application  when 
normally  the  write  permission  would  be  forbidden. 
Trusted  processes  nust  be  carefully  evaluated  for 
correctness  to  ensure  that  security  will  not  be 
carprcmised. 

Maximum  benefit  Is  derived  from  design  analysis  when  it 
is  conducted  prior  to  coding.  Design  errors  not 
detected  until  after  coding  has  commenced  may  require 
redesign  and  recoding  of  significant  program  segments 
and  thereby  increase  program  cost  and  delay  program 
schedules. 

Hie  objective  of  coda  analysis  is  to  ensure  that  the 
coded  program  correctly  and  completely  implements  the 
system  security  requirements.  Code  analysis  detects 
errors  and  deficiencies  in  the  program.  The  analysis, 
Figure  5,  evaluates  the  data  descriptions,  .interfaces, 
equations,  algorithms,  and  overall  control  logic  of  tire 
program  in  terms  of  their  adherence  to  the  security 
requirements.  Particular  attention  is  paid  to  an 
analysis  of  the  security  kernel  to  guarantee  that 
security-critical  design  functions  have  been  properly 
implemented  in  the  code.  Code  analysis  also  identifies 
extraneous  code  whose  purpose  cannot  be  traced  back 
to  the  design  or  requirements: 


Hie  techniquas  used  in  code  analysis  are  similar  to  the 
techniques  used  in  design  analysis.  Hiey  include 
program  logic  analysis,  program  data  analysis,  and 
pregram  interface  analysis.  For  example,  program  data 
analysis  examines  the  source  data  structures  in 
conjunction  with  the  program  logic  to  determine  whether 
any  possible  security  errors  such  as  data  crosstalk  or 
spillage,  inconsistent  use  of  data  types,  or  improper 
protection  of  classified  data  are  present  in  the  source 
code. 

Hie  goals  of  CSOCA  testing  differ  from  those  of  the 
testing  performed  by  the  development  organization,  who 
tends  to  focus  on  ensuring  the  program  is  functionally 
correct.  CSCCA  testing,  on  the  other  hand,  focuses  on 
locating  potential  security  weaknesses  and  identifying 
extreme  or  unexpected  situations  that  could  cause 
nonconpliance  with  the  critical  security  objectives. 

Hie  security  testing.  Figure  6,  is  an  independent 
dynamic  set  of  tests  designed  to  verify  the  results 
of  earlier  analysis,  to  investigate  program  behavior, 
to  identify  program  shortcomings,  and  to  ensure  that 
the  program  complies  with  its  security  requirements. 
CSOCA  testing  complements,  rather  than  duplicates, 
the  testing  performed  by  the  developer.  The  testing 


figure  A.  CSCCA  ?«ulng 


is  developed  in  a  methodical  manner  from  the  results 
of  the  requirements  analysis  which  determined  if 
(and  to  what  degree)  tile  systems  requirements  reflecrt 
the  security  requirements.  High  level  test 
specifications  are  written  for  each  security  require¬ 
ment-  Hiese  tests  are  designed  to  demonstrate  the 
correctness  and  effectiveness  of  each  security 
requirement. 
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CSCCA  also  uses  stress  testing  to  examine  critical 
security  funertions  during  program  execution  when  many 


demands  are  placed  on  the  system.  These  stress  and/or 
penetration  tests  will  be  developed  from  the  results  of 
our  previous  analysis  using  a  fault  tree  hypotheses. 

The  fault  tree  hypothesis,  Figure  7,  postulate 
techniques  that  could  be  used  to  exploit  the  system 
weaknesses  and  circumvent  the  system  security 
measures.  The  techniques  are  translated  into  system- 
specific  tests  to  provide  or  disprove  the  hypothesis . 
Since  it  is  impractical  and  frequently  inpossible  to 
test  all  cmbinations  of  inputs  and  program  paths,  the 
testing  performed  must  be  sufficiently  representative 
of  the  entire  spectrum  of  possible  conditions  to 
establish  confidence  in  the  security  controls  of  the 
system.  In  general,  software  development  methodologies 
do  not  establish  criteria  for  meeting  this  goal. 
However,  the  design  analysis  and  code  analysis 
activities  in  CSCCA  serve  to  generate  these  criteria. 


flflur#  7.  F*uU  Tr#t  HjrpothtiH 

The  CSCCA  effort  is  aided  considerably  by  the  use  of 
carefully  selected  software  tools  which  provide 
reliable,  cost-effective  adjuncts  to  manual  analysis 
techniques,  "tools  significantly  increase  the 
productivity  and  value  of  a  security  evaluation  effort. 
Both  static  and  dynamic  tools  can  be  used.  Static 
analysis  tools  do  not  require  program  execution;  metric 
analyzers,  requirements  tracers,  dataflow  analyzers, 
and  cross  reference  generators  are  typical  of  the  tools 
in  this  category.  Seme  operate  on  requirements  and 
design  information  supplied  by  the  analyst ,  while 
others  are  used  to  help  analyze  program  source  or 
object  code.  Dynamic  analysis  tools  include  test 
drivers,  execution  monitors,  real-time  analyzers,  data 
reduction  tools,  and  simulators.  These  tools  are  used 
to  control  program  execution,  extract  meaningful 
information  during  program  operation,  analyze  program 
results,  and  model  the  environment  external  to  the 
operating  program. 

CSCCA  is  concluded  with  a  system  validation  and. 
recommendation  for  certification.  The  purpose  of 
validation  is  to  provide  final  assurance  that  the  as- 
bulit  system  satisfies  the  specified  system  security 
requirements  and  meets  critical  security  objectives. 
Validation  provides  an  end-to-end  evaluation  of  the 
software  deliverables  against  tlie  security  requirements, 
the  security  model,  and  the  critical  security  object¬ 
ives.  Since  it  is  cannon  for  numerous  program  patches 
and  other  minor  software  changes  to  be  made  during 
the  final  stages  of  system  test  and  integration,  it  is 
crucial  to  the  success  of  the  CSCCA  process  that  a 
final  validation  of  the  entire  system  follow  delivery 
of  the  final  code. 

The  final  CSCCA  activity  is  a  certification  of  the 
object  program  delivered  to  the  program  office.  Ih.is 
two-step  process  includes:  (1)  an  internal 
verification  that  the  final-version  source  and  object 


tapes  correspond  to  one  another  and  match  the  work 
files  used  in  performing  CSCCA,  and  (2)  a  certification 
demonstration  conducted  to  confirm  the  object  tape 
delivered  to  the  program  office  is  identical  to  the 
object  tape  on  which  validation  was  performed. 

4.  Summary 

The  last  decade  has  brought  an  increased  under standing 
of  security-specific  technical  issues  inherent  in  the. 
development  of  computer  systems.  These  technical 
issues  include: 

o  Utilization  of  a  security  model  that  accurately 
reflects  the  security  requirements . 

o  Use  of  a  correctly  implemented  tamperproof 
security  kernel. 

o  Rigid  adherence  to  modem  software  engineering 
standards  throughout  all  phases  of  system 
development. 

There  now  remains  one  significant  technical  issue,  that 
is  the  need  for  a  rigorous,  independent,  and  objective 
assurance  procedure  to  meet  critical  security 
objectives. 

When  the  need  for  reliably  secure  computer  systems 
first  arose  in  the  early  1970s,  it  was  believed 
possible  to  design  and  implement  ccmputer-assisted 
assurance  procedures  which  would  be  able  to  verify  the 
correctness  of  a  program  with  mathematical  certainty. 
The  mathematical  theory  behind  such  formal  verification 
procedures  is  mostly  understood;  but  due  to  the 
complexities  of  large  systems,  the  use  of  formal 
verification  proofs  to  verify  correctness  of  actual 
programs  has  been  very  limited.  It  is  unclear  when 
this  technology  will  be  applicable  to  a  large  computer 
system. 


CSCCA  is  a  well  proven  rigorous  technique.  CSCCA 
carefully  tailors  IV&V  technology  to  the  special  issues 
inherent  in  developing  secure  computer  systems.  It  is 
a  blending  of  rigorous  ccmputer-assisted  review, 
analysis,  testing,  and  evaluation  activities  designed 
to  provide  objective  assurance  that  a  system  meets  its 
critical  security  objectives.  Computer  Security  Cross 
Check  Analysis — performed  in  conjunction  with  a  soft¬ 
ware  development  process  employing  modem  software 
engineering  principles — is  the  best,  most  cost- 
effective,  practical  way  to  realize  state-of-the-art 
computer  security  in  mission  critical  computer  systems. 

The  authors  wish  to  acknowledge  Jerry  W.  Mer&ky  and 
Bruce  H.  Wetts  for  their  contribution  in  preparing 
this  paper. 
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A  project  to  certify  a  multilevel  secure  internet 
device  has  served  as  a  vehicle  to  address  several 
design  issues  for  secure  communications  systems.  These 
issues  have  been  the  subject  of  intense  discussion  by 
the  security  community  in  recent  years.  This  paper 
specifically  covers  three  of  the  issues.  Our  approach 
to  providing  assurance  for  communications  systems  not 
only  is  doing  the  job  for  Multinet  Gateway,  but  also 
applies  to  a  broad  class  of  communications  and  other 
systems. 


INTRODUCTION 

We  are  currently  developing  an  internet  device 
that,  in  conjunction  with  other  internet  components, 
provides  a  datagram  service.  In  providing  that 

service.  it  also  provides  security  protection 

mechanisms  to  prevent  the  compromise  of  sensitive 
information.  The  security  protection  mechanisms  are  to 
be  evaluated  in  an  internet  environment  using  as  a 
basis  the  Trusted  Computer  System  Evaluation  Criteria 
(TCSEC)  at  the  A1  level  5.  TEMPEST  and  COMSEC 

certification  are  also  being  accomplished.  To 
accomplish  this,  extensive  use  of  rigorous  and  formal 
methods  are  being  employed.  The  paper  also  describes 
those  methods  in  terms  of  objectives,  motivation, 
utility  and  application  to  the  internet  device  and  its 
environment.  This  paper  describes  our  approach  to  the 
development  of  such  a  secure  distributed  system  device 
and  some  of  the  issues  such  an  effort  raises. 

The  following  list  summarizes  the  issues  covered 
in  the  process  of  the  Multinet  Gateway  certification 
project: 

•  life-cycle  issues:  re-verification  cost  and  risk 

a  documentation  relationships:  linking  formal, 

traditional,  and  other  documentation 

«  requirements  analysis:  describing  requirements 
for  enhanced  traceability  and  identifying  impor¬ 
tant  relationships  among  requirements 

a  obtaining  assurances  from  different  sources:  logi¬ 
cally  combining  constraints  on  environment  and 
component  behavior  to  satisfy  qualitative 
assurance  requirements 

•  use  of  rigor:  avoiding  the  all-or-nothing  effect 
often  associated  with  formal  methods 

•  flexibility  of  system  types:  focus  on  communica¬ 
tions  systems 


•  specification  target:  what  is  being  specified  and 
what  about  the  specification  is  to  be  verified 

a  decomposition  and  abstraction:  examination  of  the 
fundamental  ways  of  relating  components  in  a  com¬ 
plex  system 

This  paper  focuses  on  the  latter  three  issues. 
Elaborated  as  questions,  those  issues  are: 

a  Secure  system  architecture:  How  should  one  charac¬ 
terize  the  analog  of  the  trusted  computing  base 
(TCB)  for  a  communications  system  (or  any  distri¬ 
buted  system )?  What  are  the  consequences  of 
directly  extending  the  TCB  concept  to  general  sys¬ 
tems?  Have  some  fundamental  issues  been  over¬ 
looked  by  such  a  direct  extension?  16 

•  Specification  target:  What  is  the  target  of  the 
specification,  verification  and  (eventually)  cer¬ 
tification  process?  What  is  it  that  a  formal 
specification  must  describe,  and  is  it  only  to  be 
a  formal  tO£  level  specification  of  the  target?  ^ 

e  Decomposition  and  abstraction:  How  are  these  con¬ 
cepts  related?  Arc  they  merely  inverses  of  each 
other?  If  not,  how  do  we  know  when  to  use  either? 

The  remaining  listed  issues  are  discussed  in  "Rigorous 
Integration  of  Sources  of  Assurance"  and  -'Results  in 
the  Development  of  a  Multilevel  Secure  Network"  6. 

The  remainder  of  this  paper  is  organized  as  fol¬ 
lows:  The  second  section  describes  the  Multinet  Gateway 
as  an  internet  device  and  its  environment  in  terms  of 
design  constraints,  design  objectives  and  security  con¬ 
cepts.  The  third  section  describes  the  various 
development  mechanisms  that  are  being  used  in  the  Mul¬ 
tinet  Gateway  development.  Included  in  this  section 
are  the  motivation  for  newly  developed  tools  (trust 
domains)  and  concepts  (constraint  monitors).  The  Gypsy 
specification  language  is  identified  in  this  section  to 
show  how  it  integrates  with  the  development  mechanisms. 
The  fourth  section  describes  how  we  are  applying  these 
development  mechanisms  in  order  to  specify  the  neces¬ 
sary  security  characteristics  of  the  Multinet  Gateway 
internet  device.  The  paper  concludes  by  relating  our 
results  to  previous  computer  security  literature. 


SYSTEM  DESIGN  CONSIDERATIONS 

The  Multinet  Gateway  System  (MGS)  is  composed  of 
gateways  and  networks.  It  provides  an  internet 
protocol  based  datagram  service  that  permits  delivery 
of  datagrams  between  source  and  destination  hosts. 
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subject  to  the  DoD  security  policy  on  the  transfer  of 
classified  information.  The  MGS  will  be  able  to 
connect  to  networks  that  carry  data  at  one  or  more 
security  levels.  The  current  Multinet  Gateway 
certification  program  has  the  goal  of  providing  an  A1 
level  of  security  assurance  for  the  gateway  as  an 
internet  device.  The  certification  work  includes  not 
only  formal  specification  and  verification  of  the 
security-critical  software,  but  also  COMSEC  and  TEMPEST 
certification.  The  protection  mechanisms  for 
personnel.  TEMPEST,  and  COMSEC  as  well  as  the 
procedural  mechanisms  are  all  applicable  to  the  MGS, 
but  are  not  emphasized  in  this  paper. 


Design  Constraints 

inherent  in  the  design  of  any  system  are  the 
constraints  that  limit  the  design  choices: 

•  Access  to  data:  The  MGS  provides  switching 
services  that  empiov  the  lower-layer  protocols  in 
terms  of  the  0S1  Reference  Model  u.  These 
lower-layer  protocols  do  not  require  access  to 
user  data  in  order  to  perform  their  particular 
functions.  The  primary  data  objects  to  be 
protected  are  user  data  that  are  encapsulated  in 
various  protocol  layers. 

e  Well-Defined  data  structures:  The  only  way  that 
users  can  access  the  MGS  is  by  formatting  their 
data  in  accordance  with  the  specifications  of 
these  lower-layer  protocols.  These  formats  are 
well-defined  in  terms  protocol  header  fields,  data 
fields  and  trailer  fields.  In  particular,  these 
sets  of  protocols  provide  a  means  of  unambiguously 
determining  the  location  of  the  security  label  in 
the  protocol  header  (if  appropriate)  and 

determining  the  demarcation  between  the  protocol 
header/trailer  fields  and  the  user  data. 

t  External  Systems:  The  MGS  is  intended  to  function 
in  the  context  of  a  larger  system  that  includes 
hosts  and  networks  that  are  external  to  it.  The 
security  properties  of  the  MGS  must  be  considered 
in  conjunction  with  these  external  components. 
The  security  of  the  combined  components  including 
the  MGS  may  be  affected  by  the  security  attributes 
and  security  properties  of  these  external 

components. 

•  Distributed  system:  The  MGS  is  intended  to  provide 
interoperability  between  geographically  dispersed 
networks,  and  is  therefore  itself  a  geographically 
dispersed  system  with  specific  functionality  to  be 
distributed. 

e  Formal  specification  and  verification:  Formal 

specification  and  verification  techniques  are  to 
be  used  to  provide  an  increased  level  of  assurance 
that  the  mechanisms  whose  functions  are  to  prevent 
unauthorized  disclosure  of  sensitive  information 
are  correctly  implemented. 

Design  Objectives 


amount  of  security  trustworthiness  required  of 
these  protocols  will  significantly  reduce  the  MSS 
security  recertification  effort  required  as 
protocols  are  added,  deleted,  or  modified. 

e  Common  Protection  Mechanism;  Provide  security 
protection  mechanisms  that  can  be  uniformly 
applied  to  each  of  the  distributed  components  that 
make  up  the  MGS. 

e  Security  Labels:  Provide  a  means  of  associating  or 
tagging  all  (user  level)  data  processed  by  the  MGS 
with  a  security  label. 

e  Certification  of  the  COMSEC  Integration:  Ensure 
that  the  design  of  the  embedded  encryption 
function  and  the  integration  of  the  device  are 
accomplished  in  a  consistent  and  verifiable 
manner.  Related  issues  include  those  of  defining 
an  appropriate  policy,  model  and  specifications, 
which  capture  the  security-critical  functionality 
and  desired  security  properties  of  the  COMSEC 
equipment. 

a  Levels  of  abstraction:  Use  levels  of  abstraction 
as  part  of  the  design  process  for  three  purposes. 
It  will  simplify  the  task  of  evaluating  the 
security  properties  of  the  system  using  a  top  down 
approach.  It  can  modularize  the  specifications  so 
that  changes  can  be  easily  encorporated  without 
complete  re-verification.  It  can  simplify  the 
verification  process. 

Multinet  Gateway  System  Security  Concepts 

The  basic  Multinet  Gateway  System  security 
concepts  are: 

a  The  definition  of  the  system  boundary  of  the  MGS. 
The  definition  of  the  system  boundary  is  to 
incorporate  the  notion  of  various  security 
perimeters. 

A  Definition  of  all  information  units  and  access 
control  of  such  information  units  crossing  the 
boundary . 

s  The  control  of  how  data  units  are  manipulated 
while  inside  the  boundary. 

These  concepts  must  be  placed  in  context  of  the 
physical  realities  of  the  Multinet  Gateway  System.  The 
Multinet  Gateway  System  consists  of  a  set  of 
geographically  dispersed  Multinet  Gateway  Nodes.  The 
nodes  are  connected  to  client  hosts  by  networks  termed 
"End  Networks",  and  are  connected  to  each  other  by 
networks,  termed  "Transport  Networks".  A  network  that 
provides  both  end  and  transport  services  is  termed 
"Dual  Network".  Figure  1  illustrates  these 
relationships.  The  MGS  boundary  establishes  the  point 
where  security  responsibilities  start  or  end.  The 
Multinet  Gateway  System  boundary,  in  terms  of  Figure  1 
is  where  the  End  Network  connects  to  the  MG  Node.  The 
Transport  Networks  are  considered  inside:  the  MGS 
boundary. 


The  preceding  design  constraints  are  considered 
requirements  that  must  be  met  by  any  design  approach 
for  the  MGS.  In  addition  to  those  constraints,  there 
are  additional  design  objectives  which  have  further 
limited  the  potential  approaches. 

A  Security  and  protocol  processes:  Minimize  the 
security-critical  portions  of  the  protocol 
processing.  Protocol  design,  development,  and 
implementation  is  currently  undergoing  rapid 
change  as  the  technology  evolves.  Limiting  the 
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Figure  1.  Multinet  Gateway  System 

Given  the  MGS  boundary,  mechanisms  are  required  to 
control  the  access  into  and  out  ot'  the  MGS.  The 
location  of  the  access  control  is  shown  in  the  figure. 

The  concepts  underlying  the  computer  security 
protection  mechanisms  are  the  following: 

a  Within  the  MGS  a  security  label  is  associated  with 
every  information  unit  (datagram  or  other  protocol 
unit ) . 

a  An  input  security  sccess  check  is  performed  on 
every  information  unit  entering  the  MGS. 

a  An  output  security  access  checi.  is  performed  on 
every  information  unit  leaving  the  MGS. 

a  While  in  the  MGS,  information  units  will  not  be 
subject  to  unauthorized  disclosure. 

•  While  in  tht  MGS,  the  security  label  associated 
with  a  information  unit  will  not  be  corrupted. 

A  major  source  of  assurance  that  these  security  con¬ 
siderations  are  met  is  the  Secure  Communications  Sup¬ 
port  System  (SCSS).  The  SCSS  consists  of  the  software, 
executing  on  each  gateway  processor,  that  supports  the 
security  controls. 


DEVELOPMENT  MECHANISMS 

The  development  mechanisms  we  are  using  are 

summarized  as  follows: 

Trust  domains:  A  means  of  partitioning  a  distributed 
system  and  expressing  particular  constraint 
relationships. 

Constraint  monitors:  A  means  (in  conjunction  with  trust 
domains)  of  determining  what  minimum 
constraints  are  necessary  to  maintain  the 
security  of  the  system. 

Gypsy  Verification  Environment  (GVE):  A  means  of 
expressing  the  design  and  implementation 
and  proving  assertions  that  are  expressions 
of  the  constraints. 

Documentation:  An  integrated  way  of  describing  the 
system  and  its  security  attributes. 


The  distributed  nature  of  the  Multinet  Gateway 
environment  led  us  to  consider  a  rigorous  means  of 
describing  such  systems.  The  result  was  the 
development  of  the  concept  of  trust  domains  15. 
Briefly,  trust  domain  analysis  provides  a  high  level 
description  lansuase  which  can  be  used  to  describe  the 
partitioning  of  systems  into  nodes  and  links.  The 
language  provides  a  way  of  describing  how  nodes  and 
links  are  intercnonected.  how  each  can  be  broken  up 
into  subordinate  nodes  and  links,  and  how  each  can  be 
constrained  at  the  associated  interface.  These 
language  capabilities  can  then  be  used  to  focus  on  the 
security  properties  of  the  system  without  being  tied  to 
the  semantics  of  a  given  specification  language,  such 
as  Gypsy. 

Constraint  Monitors 

Tlie  trusted  computing  base  (TCB)  as  defined  in  the 
Trusted  Computer  System  Evaluation  Criteria  (TCSEC)  is 
that  software  and  hardware  used  to  enforce  the  system 
security  policy.  One  would  like  to  minimize  the  amount 
of  such  software/hardware  because  it  is  expensive  to 
produce  for  Al  systems. 

Based  on  trust  domains,  we  have  developed  the 
notion  of  a  "constraint  monitor"  to  aid  in  the 
determination  of  exactly  what  portions  of  c  system  are 
trusted  and  what  they  are  trusted  to  do.  The  term 
constraint  monitor  is  used  to  replace  such  terms  as 
"kernel",  "reference  monitor",  "trusted  process",  etc, 
to  emphasize  that  in  a  distributed  system  not  all 
functions  or  components  will  have  the  same  type  of 
behavioral  requirements  (trust). 

Gypay  Verification  Environment 

The  GVE  provides  a  capability  to  specify  and 
verify  (via  proof  techniques)  correctness  attributes  of 
systems  and  their  constituent  components,  including 
programs.  The  GVE  consists  of  a  programming  language, 
Gypsy,  a  verification  condition  generator,  a  theorem 
prover.  and  tools  for  maintaining  the  verification 
state  of  the  current  version  of  the  system  under 
development.  The  programming  language  includes 
mechanisms  for  specifying  properties  to  be  proved  about 
systems,  subsystems  and  programs  and  their 
interrelationships . 

A  significant  advantage  of  Gypsy  is  its  ability  to 
specify  and  verify  systems  which  have  concurrent 
processes,  which  is  particularly  useful  for  describing 
distributed  systems.  The  GVE  is  described  in  detail  in 
"Using  the  Gypsy  Methodology"  8. 

Documentation 

Given  the  various  design  tools  and  concepts 
menft.ned  above,  there  is  the  need  to  provide  some  way 
of  conveying  the  design  information  to  an  evaluator  in 
a  consistent  and  understandable  form.  Because  of  the 
complexity  of  typical  distributed  communication 
systems,  their  design  must  be  described  in  several' 
abstraction  levels,  in  terms  of  specific  properties 
that  are  to  be  emphasized,  in  mappings  of  how  the 

specific  properties  are  related  to  the  overall  tunc- 
tionality  of  the  system,  and  finally  how  the  various 
components  are  implemented  in  iron  and  executing  code. 
Unfortunately,  such  a  universal  description  language 
does  not  exist.  As  a  (hopefully  interim)  substitute, 
we  have  developed  procedures  to  provide  correspondence 
between  the  available  specialized  description 
languages.  A  document  termed  the  System  Security 
Description  (SSD)  is  used  to  present  the  various 
descriptions  and  their  associated  correspondences. 
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The  system  and  security  architecture  is  presented 
in  the  SSD  via  a  four-fold  representation;  an  implemen¬ 
tation.  a  functional,  a  trust  domain  and  a  Gypsy  sum¬ 
mary  description. 

The  first  description  is  an  implementation 
description.  It  includes  the  physical  location  of  the 
components,  how  they  are  interconnected,  the  allocation 
of  functions  to  software,  firmware,  and  hardware  and 
the  protection  mechanisms. 

The  second  is  a  description  of  the  functionality 
of  the  MGS.  It  describes  the  types  of  functional  pro¬ 


language)  than  the  many-to-aany  (abstraction)  mapping. 
Thus,  it  is  generally  prudent  to  apply  decomposition 
wherever  some  overriding  factor  does  not  prohibit  it. 

We  chose  to  incorporate  the  abstraction  mapping  in 
the  development  process  based  on  the  following  factors: 

a  the  need  to  structure  the  formal  specification  in 
a  way  that  relates  easily  with  the  policy  model; 

c  the  need  to  assure  certification  plug 
compatibility  of  interfaces,  i.e.,  reusability  of 
the  verification  and  certification  for  certain 


cessing  and  the  associated  relationships.  This  func¬ 
tional  description  provides  a  basis  for  another 
description  that  is  a  more  rigorous  formulation  of 
specific  security  requirements  and  their  relationships. 

This  third  description  allows  a  demonstration  that 
the  MGS  security  policy  is  satisfied  without  being  tied 
to  the  semantics  of  a  given  formal  specification 
language.  This  description  is  given  via  the  concept  of 
"trust  domains"  and  the  trust  domain  description 
language . 

The  fourth  description  is  a  summary  description  of 
the  Gvpsy  specification  of  the  MGS.  with  its  focus  on 
the  required  security  attributes.  Although  the  formal 
specification  itself  presents  a  description  of  the  MGS 
and  its  security  attributes  without  any  implementation 
or  procedural  constraints,  the  SSD  presents  a  class  of 
implementation  constraints  that  are  consistent  with  the 
formal  specification  at'  the  MGS  and  to  which  the  MGS 
implementation  belongs. 

The  final  part  of  the  SSD  provides  the  mappings 
between  the  four  descriptions  to  show  how  they 
correspond  to  one  another.  The  mappings  are 
represented  and  validated  informally. 

Together,  these  descriptions  are  intended  to 
comprise  what  is  meant  by  a  "descriptive  specification" 
as  called  out  by  the  TCSEC.  The  descriptions  permit  a 
clearer  presentation  of  the  many  aspects  of  the  design 
and  give  a  reader  a  more  complete  view  of  the  overall 
design.  These  documentation  relationships  and  the  cer¬ 
tification  approach  for  Multinet  Gateway  development 
are  discussed  in  further  detail  in  "Results  in  the 
Development,  of  a  Multilevel  Secure  Network"  6. 


ISSUE  RESOLUTION 

In  this  section  we  show  how  we  are  actually 
building  the  MGS  using  the  development  mechanisms 
presented  previously, 

Abstraction  Layering  and  Decomposition 

For  the  purposes  of  this  development,  it  seems 
appropriate  to  view  abstraction  and  decomposition  in 
terms  of  dependency  relations.  The  concept  is  that 
elements  of  a  set  "upper"  components  depend  on  the 
elements  of  a  set  of  "lower"  components.  Such  a 
dependency,  in  the  Multinet  Gateway  security  design,  is 
both  in  terms  of  function  and  constraints.  The 
distinction  between  an  abstraction  relationship  and  a 
decomposition  relationship  is  that  with  a 
decomposition,  the  relation  is  a  many-to-one  mapping 
from  the  lower  component  set  to  the  upper  component 
set.  With  an  abstraction,  the  relation  is  typically 
many-to-raany . 

The  many-to-one  versus  many-to-many  distinction  is 
significant  in  the  actual  development  process.  A 
many-to-one  (decomposition)  mapping  requires  much  less 
"bookkeeping,"  and  is  generally  supported  by  more 
automatic  tools  (such  as  the  syntax  of  the  Gypsy 


trust  domains;  and 

•  the  need  for  a  direct  relation  between  the  formal 
specification  and  various  "architectural  reference 
points"  in  the  design. 

By  an  architecture  reference  point,  we  mean  a  signifi¬ 
cant  aspect  of  the  system  architecture  that  is  taken  as 
given  and  so  must  be  reflected  by  not  only  the  system 
implementation,  but  also  by  the  formal  description  of 
the  system.  For  example,  in  a  system  of  network  gate¬ 
ways.  and  architectural  reference  point  might  include 
specific  aspects  of  the  geographical  separation  of  the 
gateway  nodes.  The  idea  of  an  architectural  reference 
point  is  that  it  constrains  the  allowed  design  space  of 
the  system. 

In  order  to  reflect  the  policy  model  in  the  formal 
specification  of  the  system,  it  was  useful  to  keep  the 
virtual  secure  transport,  acceptance  and  delivery  func¬ 
tions  highly  visible.  Also,  it  was  decided  that  the 
SCSS  external  inter  faces  should  be  explicitly 
represented  in  the  formal  specification  to  assure  its 
certification  plug  compatibility.  The  primary  formal 
constraints  (security  policy  model)  would  not  have 
necessitated  that  representation,  nor  was  the  system 
architecture  a  significant  factor.  But  the  SCSS  is 
expected  to  be  reusable,  and  its  reuse  needs  to  have  a 
minimal  verification  impact. 

The  combination  of  the  need  to  reflect  the  policy 
model  as  it  is  in  the  formal  specification  and  the 
desire  to  make  visible  the  SCSS  with  its  external 
interfaces  disallowed  direct  decomposition  from  the 
system  interface  to  the  SCSS  Interfaces.  Thus,  an 
abstraction  mapping  was  necessary  at  the  SCSS  inter¬ 
face.  with  the  two  layers  related  by  the  constraints 
satisfied  by  the  SCSS. 

in  summary,  the  decision  to  include  an  abstraction 
mapping  was  the  result  of  significant  iterations  of 
architectural  structuring  during  the  past  two  years. 

An  Examination  of  the  TCB  Concept 

When  applying  the  concept  of  a  TCB  within  the 
context  of  a  distributed  system,  there  are  some 
resulting  issues  that  can  be  quite  confusing.  A  key  to 
avoiding  such  confusion  is  to  look  at  distributed  or 
otherwise  complex  systems  in  ways  tailored  to  the 
systems  and  their  environments  i3.  Before  we  can  know 

how  to  apply  such  a  concept,  we  must  first  ask.  "What 
must  we  prove  about  what?".  First,  in  a  deeply  struc¬ 
tured  system,  it  becomes  more  clear  that  the  system  as 
a  whole  is  the  object  about  which  adherence  to  the 
security  policy  must  be  proved,  and  not  Just  some 
"security-critical"  software  (which  might  be  called  the 
TCB).  Second,  as  we  examine  internal,  derived  security 
requirements,  we  see  more  subsystems  that  are  not 
strictly  a  "TCB"  or  parts  of  a  "TCB"  about  which  those 
derived  requirements  must  be  proved.  Third,  according 
to  the  TCSEC's  definition,  the  TCB  encompasses  more 
than  developed  software.  For  example,  part  of  the 
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hardware  of  a  system  may  be  part  of  the  TCB.  Thus,  it 
may  not  be  appropriate  to  prove  some  of  the  TCB  charac¬ 
teristics,  for  various  reasons.  Fourth,  different, 
separated  parts  of  the  TCB  may  be  different  in  function 
and/or  interface,  and  must  somehow  be  related. 
Further,  some  sets  of  separated  parts  of  the  TCB  may  be 
essentially  identical  except  for  their  contexts,  and  so 
should  not  require  separate  proofs  of  their  con¬ 
straints.  Fifth,  a  distributed  system  requires  expli¬ 
cit  attention  to  the  channels  (links)  as  well  as  to  the 
computational  components  (nodes).  Links  may  be  as  com¬ 
plex  as  nodes;  in  fact,  cither  may  contain  the  other. 
Trustworthiness  of  links  may  have  to  be  demonstrated  or 
assumed,  as  with  nodes.  As  a  special  case,  trustworthy 
links  must  be  available  to  allow  communication  amor.* 
separated  components  of  the  TCB. 

The  consequence  of  these  points  is  that  distri¬ 
buted  systems  inherently  have  structure.  Ignoring  such 
structure  by  assuming  a  "system  TCB"  without  substan¬ 
tiation  detracts  from  any  confidence  associated  in  the 
assurance  mechanisms.  It  is  more  beneficial  if  there 
are  ways  to  deal  with  such  underlying  inherent  struc¬ 
ture. 

A  more  useful  view  is  an  approach  analogous  to  the 
operating  system  monitor  concept  10 .  The  paradigm  for 
that  approach  is  depicted  in  Figure  2.  The  concept  of 
a  TCB  has  been  replaced  with  "constraint  monitor." 
since  the  paradigm  is  to  be  applied  at  any  place  in  the 
system  structure  where  a  constraint  is  to  be  demon¬ 
strated.  In  particular,  it  is  not  to  be  applied  just 
at  the  system  security  policy  level.  The  paradigm 
thereby  accounts  for  both  the  traditional  TCB  concept, 
as  well  as  more  general  concepts. 


Figure  2.  Constraint  Monitor  Paradigm 


As  an  example,  let  the  "non-trustworthy"  function 
F,  identified  in  the  figure,  be  the  amalgamation  of  all 
the  application  (user)  functions  to  be  performed  on  a 


secure  operating  system.  The  constraint  monitor  is 
then  just  the  software  portion  of  the  TCB,  as  tradi¬ 
tionally  viewed.  The  "trustworthy"  function  F'  appears 
to  users  (connected  via  the  "external  interfaces")  as 
the  system  itself. 

We  now  apply  the  constraint  monitor  paradigm  to  a 
distributed  system,  such  as  the  MGS.  In  a  first  appli¬ 
cation  of  the  paradigm,  the  SCSS  is  the  constraint  mon¬ 
itor  itself.  The  non-trustworthy  functions  arc  the 
protocol  functions,  which  we  are  demonstrating  need  not 
be  trusted  with  respect  to  the  security  policy.  That 
demonstration  involves  showing  that  the  SCSS  constrains 
the  functions  appropriately,  and  that  the  only  inter¬ 
faces  to  the  functions  Involve  the  SCSS,  The  set  of 
"trustworthy  functions"  is  then  the  software  present  on 
a  particular  processor.  All  external  interfaces  to 
such  a  set  of  software  pass  directly  to  the  SUSS. 

The  paradigm  is  used  successively  in  the  MGS 
structure  until  one  arrives  at.  a  trustworthy  internet 
device,  the  Multinet  Gateway  node.  That  device,  in  its 
context,  is  another  example  of  a  constraint  monitor. 
As  with  the  SCSS,  it  is  multiply  instantiated  within 
the  MGS.  The  non-trustworthy  function  in  this  context 
is  the  set  of  transport  networks  by  which  the  internet 
devices  communicate  with  one  another.  The  paradigm  is 
applicable  here,  since  all  external  Interfaces,  i.e.. 
to  client  networks,  are  via  the  internet  devices.  As  a 
result,  the  MGS  is  a  trustworthy  version  of  the  tran¬ 
sport  function. 

Formal  Specification  Structure 

The  Gypsy  language  representation  of  the  MGS 
includes  the  MGS  interface,  the  MGS  environment,  and 
certain  subsystems,  particularly  the  Multinet  Gateway 
node  and  the  SCSS.  The  SCSS  and  subordinate  components 
are  represented  in  an  abstraction  layer  separate  from 
the  rest  of  the  system.  The  reason  for  this  is  that 
the  MGS  Outer  (System)  abstraction  follows  functional 
architectural  reference  points,  while  the  SCSS 
abstraction  follows  implementation  architectural 
reference  points.  Each  is  described  in  this  section 
along  with  an  explanation  of  their  interrelationships. 
The  previously  described  concepts  are  thereby  discussed 
in  the  context  of  a  given  specification  language. 

MGS  Outer  (System)  Description 

The  MGS  Outer  (System)  abstraction  relates 
functional  architectural  reference  points  such  as  the 
internet  structure,  protocol  layering  and  system-level 
protection  structures.  e.g.,  gateway-to-gateway 
encryption.  Figure  3  is  a  summary  of  the  specification 
decomposition  for  the  system  layer  of  the  MGS.  The 
figure  depicts  the  structure  of  the  Gypsy  procedures 
and  cobegins. 


MGS  Environment 
Cobegin: 

User  Delivery 
User  Acceptance 
MGS 

Cobegin: 

MG  Acceptance 
KG  Delivery 
MG  Derive 
Cobegin : 

E*3  Delivery 
E*3  Acceptance 
Node  Derive 
E*3  Derive 
Cobegin: 

E-Box 
D-Box 
NAP  Derive 
Cobegin: 

Label  Create 
Label  Delete 
Transport  Derive 
Cobegin: 

Transport  Deliv 
External  Transport 
Transport  Acceptance 

figure  3.  Gypsy  Specification  Tree  for  System  Layer 


MGS  Inner  (SCSS)  Description 
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SCSS  Environment 
Cobegin : 
Actuator. 

SCSS 


Cobegin 
Call  Decoder 
Call  Encoder 
Local  Functions 
Prodige 
MMI  Service 
Net  Service 
ITP  Service 
COMSEC  Service 
E3  Service 
IPC  Switch 


Figure  5.  Gypsy  Specification  Tree  for  SCSS  Layer 


Figure  a.  Specification  Diagram  for  system  Layer 


Figure  4  shows  the  upper  portion  of  the  system  Gypsy 
specification  tree  pictorially.  with  the  connections 
(Gypsy  buffers)  as  arrows.  This  figure  further 
contains  broken  arrows  that  indicate  certain 
constraints  assumed  by  some  components  and  satisfied  by 
others.  The  constraints  are  represented  in  Gypsy  by 
entry,  exit .  and  block  conditions,  along  with 
supporting  specification  functions  as  constraints. 
Note  that  while  some  of  the  constraints  have  both 
"sat.isfiers"  (tail  end)  and  "assumers"  (head  end), 
other  constraints  have  an  unconnected  tail  end.  and  so 


Figure  6  shows  the  SCSS  Gypsy  specification  tree 
pictorially.  using  the  same  representations  as  in 
Figure  4.  In  this  figure,  broken  arrows  (constraints) 
either  have  both  ends  connected,  or  else  have  an 
unconnected  head  end,  and  so  are  attached  only  to 
"satisfiers,"  Such  constraints  need  not  be  assumed  by 
any  domains  in  the  SCSS  layer,  but  rather  are  intended 
to  satisfy  boundary  condition  constraints  in  the  system 
layer.  That  connection  of  constraints  is  accomplished 
via  the  formal  mapping  described  in  the  "Mapping" 
paragraph,  below.  The  abstraction  layer  that  underlies 
the  SCSS  layer  is  the  Gypsy  computational  model.  The 
SCSS  assumes  that  the  Gypsy  layer  operates  correctly 
according  to  Gypsy  semantics.  The  Gypsy  layer  in  turn 
assumes  that  the  hardware  operates  according  to  the 
security-relevant  constraints  that  will  be  specified 
for  it. 
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are  attached  only  to  "assumers."  Such  constraints,  in 
the  svstem  layer,  are  treated  as  boundary  conditions. 
It  is  only  via  the  formal  mapping  between  this  layer 
and  the  SCSS  layer  that  those  constraints  are  demon¬ 
strated  to  be  met  (cf.  "Mapping"  paragraph,  below). 


Figure  6.  Specification  Diagram  for  SCSS  Layer 


At  completion,  the  SCSS  formal  decomposition  and 
the  SCSS  imolementation  software  will  be  in  a  one-to- 


135 


one  relationship  in  ten, is  of  modules.  It  will  be  given 
to  a  level  of  detail  sufficient  that  within  each 
module,  the  determination  of  whether  the  implementation 
corresponds  to  the  specification  constraints  will  be 
simpler  and  less  prone  to  error  than  previous  develop¬ 
ment  efforts 

Napping  Between  the  System  and  SCSS  Abstractions 

Pour  fundamental  concepts  characterize  the  mapping 
between  the  SCSS  and  system  layers: 

a  constraints,  rather  than  structures,  are  mapped; 

it  constraints  of  the  system  layer  that  must  be 

satisfied  by  the  SCSS  are  left  as  boundary 

conditions,  assertions  that  may  be  assumed  but 

whose  proof  is  deterred; 

a  a  set  of  constraints  intended  to  map  to  the 

unproved  system  constraints  are  proved  within  the 
SCSS  layer  specification;  and 

a  one  or  more  Gypsv  scopes  are  provided  containing 
functions  to  map  the  proved  SCSS  constraints  to 
the  unproved  system  constraints. 

The  primary  mappings  are  depicted  in  Figure  7. 
The  figure  contains  a  simplified  version  of  Figures  4 
and  6.  In  addition,  the  figure  contains  "junction 
boxes"  in  the  center,  which  represent  the  mapping 
functions  that  allow  the  upper  and  lower  versions  of 
the  constraints  to  connect. 
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Figure  7.  Constraint  Mapping  Between  Abstraction 
Layers 


The  mapping  functions  themselves  are  of  two  types: 
type  mappings  and  constraint  function  mappings.  The 
type  mappings  resolve  the  differences  in  Gypsy  types 
between  the  two  abstraction  layers.  The  constraint 
function  mappings  express  the  system  layer  Gypsy 
functions  naming  the  constraints  in  terns  of  the 
analogous  SCSS  layer  Gypsy  functions. 

RESULTS  AND  CONCLUSIONS 

Much  of  the  assurance  at  the  A1  level  that  is 
based  on  an  application  of  formal  specification  and 
verification  techniques  is  predicated  on  a  formal  model 
of  the  security  policy  and  a  formal  specification.  It 
appears  that  most  of  the  discussion  surrounding  policy 
models  and  formal  specifications  seems  to  center  on 
three  aspects:  the  level(s)  of  abstraction  of  the 
policy  and  system  description,  the  actual  target  of  the 
description  (e.g.,  entire  system.  particular 
components,  explicit  functionality)  and  the 
appropriateness  of  existing  models  including  specific 
interpretations  of  them  (e.g.,  Bell-LaPadula  the 
Military  Message  System  12 .  Two-Level  Model  7).  This 
paper  asserts  that  pArt  of  the  criteria  for  a  model's 
appropriateness  should  include  whether  one's 
understanding  of  the  targeted  system  is  actually 
increased  (both  of  the  design  and  what  is  verified) 
rather  than  forcing  an  interpretation  of  a  model  such 
as  the  Bell-LaPadula  model. 

For  the  MGS,  the  security  policy  model  is  an 
abstract  model  with  a  structure  for  explicit 
instantiations  to  provide  a  collection  of  distinct 
policies  (which  may  become  constraints  on  specific 
portions  of  the  MGS)  that  are  consistent  with  the  more 
abstract  policy  model.  In  terms  of  the  previously 
identified  aspects,  the  target  of  the  policy  model  and 
the  formal  specification  is  the  entire  MGS  as  an 
internet.  The  formal  specification  provides  a 
description  of  the  internet  system  down  to  particular 
routines  executing  on  particular  processors  within  a 
given  node  of  the  MGS.  Although  the  rules  of  the 
Bell-LaPadula  model  are  applicable  to  the  environment 
of  the  MGS,  they  are  less  so  to  the  datagram  service 
provided  by  the  MGS  and  for  the  lower  protocol  layers. 
This  is  in  concurrence  with  an  observation  made  by 
Denning  at  the  1985  Invitational  Workshop  on  Network 
Security  3 .  The  observation  is  that  those  viewing  a 
network  as  a  distributed  resource  manager  (higher 
levels  of  the  ISO  model)  find  less  trouble  with  the 
TCSEC  than  those  who  view  a  network  as  a  communications 
subnet  (lower  levels  of  the  ISO  model).  The  Multinet 
Gateway  modeling  approach  has  provided  a  means,  via  the 
trust  domain  representation  and  the  formal 
specification  approach,  to  tie  these  views  together 
without  forcing  interpretations  that  do  not  aid  the 
overall  understanding  ol'  the  system.  A  key  aspect  of 
the  approach  being  taken  is  that  a  effective  framework 
for  the  various  descriptions  is  provided  so  that  an 

interpretations  of  a  security  requirements  (according 
to  the  TCSEC)  can  be  analyzed  in  a  rigorous  manner. 

Bell  2  raised  the  issue  of  the  exact  manner  of 
intertwining  the  development  of  the  formal  top-level 
specification  ( FTLS )  and  descriptive  top-level  specifi¬ 
cation  ( DTLS ) .  The  intertwining  of  the  FTLS  and  DTLS 
issue  is  resolved  within  the  Multinet  Gateway  develop¬ 
ment  process  via  the  production  of  the  four  types  of 
descriptions  discussed  in  the  "DEVELOPMENT  MECHANISMS" 
section  and  the  relationships  among  them.  A  conse¬ 
quence  of  this  is  a  clearer  design  certification  chair, 
down  to  the  implementation  of  the  security  mechanisms 
within  the  enhanced  ADM  and  their  relationship  to  the 
whole  MGS. 
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An  additional  contribution  of  our  approach  is  a 
way  of  addressing  a  relatively  hard  problem  in  the 
specification  of  system-wide  and  component  specific 
aspects  as  described  by  Schaefer  and  hell.  The  "... 
problem  is  how  to  be  assured  that  the  collection  of 
component  specifications  support,  are  consistent  with, 
and  actualize  the  system-level  specification  ,..."  17. 
They  correctly  point  out  the  difficulty  of  handling 
such  a  process  in  present  formal  verification  systems. 
The  objective  is  to  provide  an  association  between  an 
expression  of  the  requirements  and  design  at  one  level 
and  derived  requirements  and  design  at  another  level. 
As  part  of  the  Multinet  approach,  such  an  association 
between  levels  of  system  description  is  achieved. 

Finally,  based  on  Initial  results,  it  appears  that 
the  approach  outlined  here  offers  a  way  of  lowering  the 
overall  cost  of  the  specifi  ition  and  verification  pro¬ 
cess.  This  is  due  to  the  way  that  a  reasonable  and 
reusable  problem  domain  can  be  described  in  a  con¬ 
sistent  manner  in  shorter  time  and  communicated  to  peo¬ 
ple  not  all  of  whom  are  experts  in  a  given  formal 
specification  language.  This  is  consistent  with  the 
observations  and  suggestions  offered  by  Good  9 .  The 
approach  also  helps  reduce  the  technical  risk  in  an 
application  of  the  formal  specification  and  verifica¬ 
tion  technology. 

In  conclusion,  this  paper  has  examined  some  secu¬ 
rity  Issues  that  have  been  under  discussion  in  the 
security  community  in  recent  times.  Based  on  the  work 
already  accomplished  for  the  certification  of  an  Mul¬ 
tinet  Gateway  internet  device,  an  analysis  and  assess¬ 
ment  of  the  issues  has  been  made  and  results  discussed, 
Much  of  the  basis  for  the  assessment  is  due  to  the 
engineering  work  necessary  to  produce  an  advanced 
development  model  of  an  internet  device  and  to  demon¬ 
strate  the  feasibility  of  the  design  concepts.  This 
was  accomplished  by  building  such  a  device,  by  having  a 
parallel  effort  to  prototype  some  of  the  technical 
aspects  for  the  security  certification  of  the  device 
and  by  incorporating  the  prototype  results  into  the 
formal  specification  and  verification  of  the  system, 
questions  raised  in  the  literature  and  calls  for 
research  in  specific  areas  have  been  addressed  by  the 
sharing  of  results  obtained  in  the  given  context,  Mul¬ 
tinet  Gateway.  Although  the  focus  presented  here  is 
but  one  way  to  consider  the  underlying  issues,  it  is 
felt  that  the  results  are  applicable  to  a  wider  range 
of  systems  under  development  or  being  planned. 
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abstract 

Seourity  and  fault-tolerance  are  oritioal 
requirements  in  many  distributed  systems, 
especially  in  those  supporting  real  time 
applications.  For  f ault-tolerenoe ,  redundancy 
techniques  are  being  applied  in  hardware  or 
software  to  attain  fault  masking  and  graceful 
degradation  capabilities.  For  seourity, 
variouo  .  approaches  are  being  proposed  for 
distributed  system  use.  This  paper  examines 
interactions  between  seourity  and  fault- 
toleranoe  generloally  and  with  the  help  of  a 
oaae  study.  It  oonoludes  that,  for  fault- 
tolerant  seourity,  hardware  implemented  redun¬ 
dancy  techniques  are  to  be  preferred  over 
software  implementations. 


INTRODUCTION 

A  reoent  trend  in  oomputer  system  ar¬ 
chitectures  is  to  design  and  implement  dis¬ 
tributed  nystems  where  sets  of  processing 
units  (PUs)  (each  with  its  own  privato  memory 
and  I/O  devioes) ,  global  memories,  and  data 
bases  are  interoonneoted  by  looal  area  net¬ 
works  (LANs).  The  distributed  system  architec¬ 
ture  has  several  useful  features:  the  process¬ 
ing  power  of  the  system  oan  be  increased  (or 
deoreased)  by  adding  PUs  (or  removing  them); 
availability  and  reliability  ure  enhanced  by 
virtue  of  multiple  PUs,  data  bases,  eto.  such 
that  these  units  oan  be  used  to  back  up  eaob 
other;  and  oout  is  lower,  as  compared  to  using 
a  mainframe  oomputer  with  the  same  processing 


power  (if  euoh  a 
all) . 

oomputer 

is 

available  at 

Distributed 

processing 

is 

the  preferred 

architecture  in  a 

variety 

of 

real-time  ap- 

plications,  such 

as  oommand- 

coutrol  systems 

for  the  military,  process  control  systems,  air 
traffic  control,  and  others.  These  systems 
must  be  highly  reliable  and  available,  and 
they  aro  also  likely  to  ooctain  or  prooess 
sensitive  Information,  and  require  that  the 
integrity  of  operational  data  and  programs  be 
protected.  In  these  systems,  data  seourity  and 
Integrity  become  additional  design  require¬ 
ments.  Some  of  these  systems  serve  large 
communities  of  users  who  have  different 
eeourity  olearanoes  or  need  to  know.  For 
efficient  resouroe-sharing  operation,  multi¬ 
level  seourity  (MLS)  would  be  required  in 
these  systems. 

Given  the  requirements  for  fault- 
toleranoe,  graceful  degradation,  and  data 
seourity,  a  number  of  questions  about  the 
interactions  of  these  requirements  arise  and 
need  to  be  resolved: 


Are  the  techniques  for  aohieving 
fault-toleranoo  and  data  seourity 
fully  compatible?  If  not,  what  are 
the  problems,  and  how  oan  they  be 
resolved?  What  tradeoffs  are  avail¬ 
able? 

How  does  tho  architectural  design 
for  f ault-toleranoe  impact  the 
design  for  seourity,  and  vice 
versa?  How  oan  the  designs  be  made 
compatible? 

. Can  data  saourity  be  graoefully 
degrading?  Can  graoefully  degrading 
systems  be  data  secure?  Is  there  a 
difference  in  aohieving  eaoh? 

This  paper  addresses  the  above  questions 
generloally  in  terms  of  the  suitability  of 
various  strategies  and  techniques  of  fault- 
toleranoe  in  sytems  where  seourity  is  also 
required.  A  brief  Illustration  of  implementa¬ 
tion  problems  is  provided  by  examining  MuTEAM, 
an  existing,  experimental  distributed  system 
with  fault-tolerance,  from  the  point  of  view 
of  rendering  it  multilevel  seoura. 


FAULT-TOLERANCE  HamVEa 

In  this  paper,  "seourity11  is  defined  in 
terms  of  the  implementation  and  enforcement  of 
the  DoD  seourity  polloy  aooordlng  to  the  DoD 
trusted  oomputer  system  evaluation  criteria '* . 
Slnoe  the  design  requirements  and  techni¬ 
ques  for  security  are  well-known  they  need 
no  further  explanation  in  this  paper. 

"Fault  tolerance"  is  defined  as  the 
capability  of  a  system  to  function  oorreotly 
according  to  its  design  specif ioatlons  despite 
of  the  ^presence  of  transient  or  permanent 
faults-3’  .  Suob  faults  may  ooour  in  the  hard¬ 
ware  for  various  reasons,  and  they  may  be 
present  in  software  in  the  form  of  undetected 
"bugs"  created  in  the  deslgu  or  programming. 
Their  effeots  are  "errors"  in  data  values 
and/or  in  program  behavior.  Indeed,  one  may 
view  seourity  techniques  as  a  subset  of  fault- 
toleranoe  slnoe  they  are  also  attempting  to 
handle  faults,  but  these  faults  may  be 
deliberately  introduced  and  they  tend  to  be 
very  complex.  Fault-toleranoe  techniques  tend 
to  be  less  known  and,  thus,  a  brief  summary  of 
these  is  provided  below. 

Fault  toleranoe  is  based  on  the  use  of 
"special"  redundancy  (roplioated  modules)  or 
"temporal"  redundancy  (repeated  computations) . 
Spaoial  redundancy  is  also  known  as  "protec¬ 
tive  redundancy"  --  tho  noourrenoe  of  oertain 
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faults  la  masked  entirely  by  use  of  redundant 
hardware  or  software.  A  specified  number  (but 
a  minority)  of  the  redundant  units  may  fall 
without  affecting  the  oorreotness  the  results 
or  the  system  operation.  That  is,  faults 
remain  invisible. 

An  example  of  protective  redundancy  in 
hardware,  is  N-modular  redundancy  (where  N  is 
odd).  N  replicated  modules  perform  the  same 
operations  in  parallel.  Their  outputs  are 
connected  to  a  majority  voting  unit  of  N 
voters  which  considers  as  oorreot  the  output 
from  the  majority  of  the  modules.  Some  of  the 
voters  in  the  unit  may  beoome  faulty  them¬ 
selves,  but  the  set  performs  oorreotly  if  less 
than  half  of  the  voters  are  faulty. 

Another  protootlve  redundancy  technique  is 
the  use  of  error-oorreoting  codes.  Thess  mask 
the  ocourrenoe  of  a  speoifled  number  of  simul¬ 
taneous  faults  (l.e.,  erroneously  inverted 
bits),  or  speolfied  patterns  of  faults,  in  the 
enooded  data  unit.  Of  course,  hardware  or 
software  design  flaws  or  erroneous  input  data 
valuos  cannot  be  oorreoted.  These  require 
different  approaches,  suob  as  the  "design 
diversity"  technique  ,  and  various  data  in¬ 
tegrity  techniques,  suoh  as  reasonableness 
tests . 

Temporal  redundancy  is  also  known  as 
"corrective  redundancy".  Here  the  ooaurrenoe 
of  faults  must  be  detected  and  diagnosed, 
before  oorreotive  action  nan  be  taken  (l.e., 
isolation  of  tho  failed  unit  and  aotivation  of 
a  replacement  unit),  and  recovery  from  failure 
effeots  aan  be  Initiated.  Corrective  redun¬ 
dancy  is  implemented  is  mainly  in  software, 
but  hardware  units  can  also  bo  used  to  enhanoe 
performance.  More  speoifloally ,  the  following 
actions  and  preparations  are  required. 

Fault  detection .  can  be  implemented  in 
hardware  or  software.  Hardware  techniques 
inolude  the  use  of  error  detection  oodes, 
self-choking  clroultry,  and  comparison  of  the 
outputs  of  replioatod  modules.  Software  imple¬ 
mented  detection  inoludes  computation  of 
cheokaums  and  other  authentication  functions, 
periodio  oheoklng  of  the  hardware  functioning, 
various  renoor ableness  and  limit  tests  applied 
to  data  valuos,  repeated  evaluation  of  the 
same  funotlon  with  the  same  data,  and  inter¬ 
spersing  testing  data  with  operational  data. 
In  distributed  systems,  testing  of  processing 
units  (PUs)  by  other  PUs  in  the  system  is  a 
sophisticated  detection  strategy  Which  Will  be 
examined  luter. 

Fault  diagnosis .  is  an  activity  whiob 
strives  to  looate  the  fault  and  confine  tho 
damage.  The  use  of  diagnostic  programs  is  one 
approaoh.  These  may  be  applied  by  the  local 
operating  system  or  even  from  remote  diagnos¬ 
tic  oenteru  without  the  knowledge  of  the  users 
and,  thus,  raise  security  Issues. 

Reoo  /erv .  is  the  activity  of  plaoing  the 
system  baok  into  an  error-free  state  from 
whloh  normal  operation  can  resume.  This  in¬ 
cludes  correcting  any  erroneous  changes  made 
when  the  system  was  affeoted  by  a  fault  whloh 
had  not  yet  been  deteoted.  Typically,  suob 
error-free  system  states  are  stored  periodi¬ 
cally  for  tkis  purpose  as  "roll-back"  states, 
'lorreoting  erronous  data  values  is  a  muoh  more 


dlffioult  task,  unless  steps  are  taken  in  the 
system  design  to  provide  audit  trails  for  data 
base  updates,  or  "recovery  caches"  where 
changed  data  values  are  colleoted.  With  these 
means  it  is  possible  to  restart  the  computa¬ 
tion  and  restore  the  data  values  at  the  roll¬ 
back  point. 

Reconfiguration  is  the  activity  of  remov¬ 
ing  from  the  system  a  failed  unit,  and  replac¬ 
ing  it  with  a  a  oorreotly  operating  one.  The 
replacement  unit  may  have  been  assigned  in 
advanoe  or  may  be  ohosen  from  a  pool  of  avail¬ 
able  units.  This  activity  may  also  inolude 
transporting  programs  and  data  to  new  unite 
and  removing  programs  and  data  from  a  failed 
unit. 

If  recovery  and  reconfiguration  have 
succeeded  in  restoring  the  uystea  into  an 
operational  state,  but  with  less  than  nominal 
capabilities,  the  system  has  "degraded 
gracefully".  The  degradation  may  be  in  the 
form  of  a  reduction  in  the  system's  perfor¬ 
mance,  memory  oapacity,  number  of  prooessors 
available,  and  the  like.  One  prerequisite  for 
graceful  degradation  is  redundancy  in  each 
type  of  modules,  suoh  that  the  failure  of  a 
module  can  be  handled  by  the  remaining  modules 
of  the  same  type  whloh  assume  the  funotions  of 
tho  failed  module. 


FAULT-TOLEBAHT  mill 

Since  the  purpose  of  implementing  fault- 
tolerance  is  to  eliminate  the  disruptive 
impacts  of  faults  on  the  funotions  being 
performed,  it  is  of  interest  to  apply  fault- 
tolerance  techniques  also  to  the  ssourity 
function.  The  prinoipal  purpose  or  this  func¬ 
tion  is  to  make  decisions  on  attempts  by  a 
system's  subjects'  (e.g.,  users,  processes)  to 
gain  aooess  to  the  system's  objects  (e.g. 
memory  segments,  files,  programs).  The 
seourlty  funotlon  is  fault-tolerant  if, 
despite  of  faults  in  the  system,  the  security 
decisions  oorreotly  enforce  the  system's 
seourlty  polioy,  the  associated  deoision 
support  data  (l.e.,  identlf loations ,  seourlty 
labels,  aooeus  rules)  remain  oorreot,  no 
sensitive  data  are  erroneously  released,  no 
oovert  obannels  are  introduoed,  and  no  denial 
of  servloe  event  takes  place.  We  will  now 
examine  the  suitability  for  seourlty  purposes 
of  the  protective  and  oorreotive  redundancy 
approaches  to  f ault-toleranoe . 

Protective  redundancy ,  implemented  in 
hardware,  and  the  use  of  error-correcting 
oodes  appear  to  be  suitable  teohniques  for 
fault-tolerant  seourlty,  provided  that  oertain 
precautions  are  taken  and  the  assumptions  made 
about  the  number  and  patterns  of  errors  are 
kept  in  mind.  An  Important  consideration  is 
the  -granularity  of  applying  protective  redun¬ 
dancy,  l.e.,  the  size  of  the  replioatod 
modules.  The  finest  granularity  is  at  the 
individual  logio  function  level.  A  very  ooarse 
granularity  is  at  the  individual  processor 
level.  In  general,  the  ooarser  the  granularity 
the  more  semantio  content  there  is  in  the 
module's  output  suoh  that  sensitive  informa¬ 
tion  might  be  extraoted. 

For  example,  a  permanent  fault  in  the 
oontrol  unit  of  one  of  a  replioatod  set  of 
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data  encryption  units  may  oause  data  to  be 
released  unencrypted,  but  the  majority  of 
encryption  units  would  produce  correctly 
enoryptod  output  and  the  voters  would  step  the 
unencrypted  data  stream.  Thus,  a  replioated 
module  set  must  be  encapsulated  suoh  that  only 
the  outputs  from  the  voters  are  visible  from 
outside  the  module  set.  Even  then,  failure  cf 
a  voter  may  still  allow  the  inoorreot  output 
to  exit  from  the  replioated  set.  The  use  of  a 
shared  bus  to  send  module  outputs  to  be  voted 
upon  elsewhere  is  clearly  not  aooeptable  for 
security . 

Corrective  redundancy .  as  disoussed  above, 
involves  detecting  and  diagnosing  fault  occur¬ 
rences,  disconnecting  the  faulty  modules,  and 
then  taking  corrective  aotion  (e.g.,  recomput¬ 
ing  a  program  from  its  last  error-free 
"recovery  point").  Reoovery  also  includes 
informing  the  reoepienta  of  potentially  er¬ 
roneous  results  of  the  problem  and,  after 
recovery,  sending  the  oorreot  results.  As 
disoussed  in  [ 3 ) «  in  a  highly  interactive  dis¬ 
tributed  system  this  may  oreate  a  "domino 
effeot"  of  correction  and  reoovery  activities 
when  reoepienta  of  erronous  Information  have 
passed  it  on  to  others,  and  all  those  involved 
must  undergo  oorreotion  and  recovery. 

in  general,  this  mode  of  operation  appears 
to  be  incompatible  with  the  security  require¬ 
ments,  ainae  the  errors  in  seourity  funotlons, 
and  their  consequences ,  may  not  be 
recoverable.  For  example,  if  the  reference 
monitor  malfunctions  and  permits  writing  of 
files  in  violation  of  the  "-property,  a 
seourity  oomprouise  may  result,  important  here 
is  the  time  interval  from  fault  ooourrenoo  to 
its  detection  and  diagnosis  (the  error  latency 
time).  If  this  time  le  sufficiently  short 
(error  deteotion  test  are  performed  very 
frequently),  it  may  bo  possible  to  recover 
without  any  seourity  compromises  having  oc¬ 
curred. 

However,  it  may  also  be  feasible  to  design 
the  system  for  near-continuous  self-testing  of 
its  seourity  functions,  especially  immediately 
prior  to  any  aooess  oontrol  or  information 
release  decisions,  so  that  some  form  of  cor¬ 
rective  redundancy  could  still  bo  used.  Fur¬ 
thermore,  in  speolal  subsystems  suoh  as  local 
area  networks  (LANs),  oorreotlve  redundancy  is 
used  in  the  form  of  retransmission  upon  error 
deteotion.  This  may  be  aooeptable  from 
seourity  point  of  view  if  the  LAN  interface 
units  arc  trusted  to  reject  oonmunioatior.s 
which  would  violate  the  seourity  policy. 


CPACfiFOL  DEGRADATION  fi£  SECURITY 

A  system  can  degrade  graoefully  if  it  oan 
remain  operational  with  diminished 
capabilities  dospito  of  the  presence  of  faults 
which  oannot  be  masked  by  fault-tolerant 
design  teohniques.  A  prerequisite  is  that  the 
hardware  modules  be  replioated  so  that  no 
single  Tailure  could  totally  disable  the 
system.  The  question  is:  Can  the  security 
function  degrade  graoefully? 

If  we  use  the  DoD  seourity  criteria  as  a 
model,  as  proposed  in  Ref.  6,  degradation  of 
seourity  oan  be  viewed  in  torus  of  downward 
migration  in  the  criteria  divisions  and 


olaases.  For  example,  a  failure  in  the  TCB 
hardware  may  oause  the  loss  of  aomo  security 
mechanism  which  would  oause  the  TCB  to  fail  to 
meet  some  oritorion  of  its  ourrent  evaluation 
division  and  alass,  but  still  meet  the 
criteria  of  a  lower  olass  of  this  division  or 
of  a  lower  division.  Thus,  a  system's  security 
level  may  migrate  from  A1  to  B3,  to  B2,  end  so 
forth  as  faults  ooour.  Correspondingly,  the 
authorized  application  mode  of  the  system 
would  migrate  from  multi-level  secure  (MLS), 
to  oontrolled  mode,  to  system-high  or  dedi¬ 
cated  modes. 

Thus,  it  appears  that  in  principle  grace¬ 
ful  degradation  of  seourity  is  a  feasible 
conoept.  In  praotioe,  however,  it  would  be 
necessary  to  develop  a  syatom  design  where 
seourity  mechanisms  are  implemented  modularly 
with  diagnostics  available  to  test  each 
module's  oorreot  operation.  Upon  detecting  a 
failure,  there  would  be  a  need  for  rapid 
oontainement  of  all  subjects  and  objeots  until 
a  new  (lower)  seourity  level  has  been  deter¬ 
mined,  decisions  have  been  made  about  the 
subjects'  authorisations,  and  all  data  no 
longer  permitted  in  the  system  have  been 
safely  removed.  How  this  might  be  implemented 
is  not  yet  olear. 


afiCffi  mkI-I.9.LgRA]jC£ 

Implementing  seourity  in  systems  where 
computational  fault-toleranoe  is  also  required 
raises  caw  Issues  for  teourlty.  The  reoent 
trend  Is  toward  the  use  of  oorreotlve  redun¬ 
dancy,  rather  than  hardware  implemented 
protective  redundancy.  As  pointed  out  earlier 
in  thio  seotion,  this  may  not  be  fully  compa¬ 
tible  with  seourity  requirements.  The  repli¬ 
oated  modules,  too,  tend  to  be  more  complex 
and  so  the  redundanoy  granularity  in  coarser. 
All  this  makes  the  system  more  complex  aud 
creates  new  information  flows.  Thus,  there  are 
more  eeourity-related  problems  to  resolve: 
proving  oorreotcess  of  the  design  and  im¬ 
plementation,  and  analyzing  the  system  for  now 
information  flows  and  new  covert  channels. 

Software-implemented  oorreotlve  redun¬ 
dancy  is  usually  based  on  the  "backward 
reoovery"  concept  --  intermediate  results  of 
computations  and  system  state  information  are 
stored  periodically  as  "reoovery  points"  and, 
if  error  is  detected,  computation  is  restarted 
from  the  most  reoent  reoovery  point.  Several 
oopiee  of  reoovery  information  may  bo  kept  to 
allow  backup  of  faulty  modules.  This  increases 
the  exposure  potential  of  sensitive  informa¬ 
tion  and  complicates  meeting  the  seourity 
requirements. 

To  illustrate  the  seoure  fault-toleranoe 
problems,  we  will  briefly  disouas  HuTEAM,  a 
distributed  multlmioroprooessor  system 
prototype  developed  in  Italy'-11.  This  system 
is  intended  to  serve  as  a  development  veohlole 
for  design  methodologies  of  real  time  dis¬ 
tributed  systems  applications.  It  operates  in 
a  decentralized  oontrol  mode  without  a  central 
supervisory  control  entity,  and  it  Includes  an 
Integrated  set  of  fault-toleranoe  mechanisms 
in  the  system  programming  language,  architec¬ 
ture  and  run-time  support.  Its  main  goals  are 
to  achieve  modularity,  expandability  and 
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fault-tolaranoc  and  to  maintain  a  concurrent 
processing  env.  .•onment  in  eaoh  proooasing 
unit. 

The  system  ia  organized  into  a  aat  of 
clusters  of  up  to  16  computer  elements  (or 
"nodes").  These  are  oonneoted  via  a  "cluster 
bus* ,  and  a  "signalling  bus*.  The  interconnec¬ 
tion  topology  aatisfien  the  requirement  that 
eaoh  pair  of  nodes  is  oonneoted  by  at  least 
one  communication  path,  despite  any  single 
link  failure.  All  interprooessor  communication 
is  based  on  message  passing  using  the  shared 
memories  at  nodes,  Aooess  control  list  tech¬ 
nique  is  used  for  protecting  segments  in  the 
sbured  memory. 

MuTEAM's  f ault-toleranoo  is  based  on 
separate  phases  of  fault  deteotion  and  diag¬ 
nosis  ,  reconfiguration,  and  recovery.  A  fault 
in  a  node  is  viewed  as  rendering  the  node 
totally  faulty  and  it  is  disconnected  from  the 
rest  of  the  system.  A  faulty  node  is  isolated 
from  the  non-faulty  onos  by  the  latter  delet¬ 
ing  all  aooess  permissions  of  processes  in  the 
faulty  node.  Processes  from  a  faulty  node  are 
reallocated  to  non-faulty  nodes  based  on  prior 
pairing  of  nodes  with  their  "twins".  All  these 
operations  have  considerable  security  implica¬ 
tions. 


Even  if  the  trustworthiness  of  the  operat¬ 
ing  system  were  not  in  doubt,  there  would  be 
problems  in  applying  the  present  MuTEAM's 
f ault-toleranoo  system  to  processes  and  data 
objects  wkioh  have  different  seourity  levels. 
There  Is  a  great  deal  of  message  exchange 
between  processes  for  diagnosis,  reconfigura¬ 
tion,  and  recovery.  Violations  of  the  *- 
property  ooour  whenever  two  prooesses  at 
different  security  level  exchange  messages,  or 
the  receiver  process  sends  some  aoknowledge- 
uent  or  test  result.  To  handlo  this,  either 
the  fault-tolerance  functions  would  have  to  be 
viewed  as  trusted  prooesses  which  arc  per¬ 
mitted  to  violate  the  security  polloy,  or 
f ault-tolcranoe  would  have  to  be  implemented 
on  prooess  subaets,  eaoh  at  a  particular 
aeourlty  level.  Further,  the  communications 
performed  for  fault-tolerance  purposes  may 
permit  covert  channels  which  could  be  used  by 
Trojan  Horees  in  fault-tolerance  software. 
More  generally,  it  may  be  possible  to  spoof  a 
node  to  enter  the  fault  deteotion  and  diagnos¬ 
tics  mode  muoh  more  frequently  than  normal  to 
reduce  the  aystem  throughput. 


With  cn  untrusted  operating  syatem, 
seourity  would  he  implemented  by  dedicating 
specific  nodes  to  single  seourity  lovele  and 
implementing  the  security  policy  with  truated 
interface  units  (TIUs).  Thase  label  all  outgo¬ 
ing  massages  with  the  node's  highet  seourity 
level.  The  effoct  of  this  is  to  form  subnet¬ 
works  of  nodes,  eaoh  for  a  different  clas¬ 
sification  level  (omitting  any  consideration 
of  categories  st  this  tins).  Sines  messages 
with  responses  cannot  be  exchanged  between 
subnetworks  without  violating  the  seourity 
policy  or  requiring  the  use  of  a  Guard  module, 
eaoh  subnetwork  would  need  to  be  made  fault- 
tolerant  by  itaelf,  using  the  MuTEAM  approach. 
One  possible  oonsequenoe  of  this  is  the  need 
of  more  of  the  redundant  nodes  than  indicated 
by  the  computations  to  be  performed  to  oontain 
the  twin  backup  prooeaaes. 

MuTEAM  reconfiguration  approach  is  baaed 
on  an  a  priori  allocation  of  twin  prooeaaes  to 
baokup  nodes  and  storage  of  recovery  point 
Information  at  these  evdos.  However,  if 
dynamio  reconfiguration  sod  reoovery  were 
introduced,  additional  problems  would  arise. 
For  example,  if  there  is  no  node  available 
with  appropriate  seourity  level,  it  would  be 
necessary  to  prepare  such  a  node  either  by 
upgrading  or  downgrading  its  nominal  seourity 
level.  In  the  former  oase,  the  other  prooessee 
in  the  node  would  get  their  outgoing  messages 
labelled  higher  and,  henoe,  they  may  not  be 
Able  to  maintain  previous  communications 
without  using  the  time  consuming  Guard 
prooess.  In  the  latter-  oase,  the  higher- 
oXeaalfied  prooesses  in  the  node  would  need  to 
he  purged  before  releasing  it  to  the  backup 
role. 

Clearly,  imposing  a  seourity  requirement 
on  a  fault-tolerant  system  auoh  as  MuTEAM 
onuses  a  number  of  problems  which  tend  to 
oomplioate  the  system  or  inoresse  its  size,  or 
both.  Vbethor  or  not  s  suitable  eolution  oan 
be  found  requires  further  study. 


CONCLUDING  REMAKES 

We  have  attempted  to  establish  s  framework 
for  determining  the  impaots  of  combining 
seourity  and  fault-tolerance  in  distributed 
systems,  and  to  sot  a  stage  for  further 
researoh.  The  preliminary  conclusions  are  that 
(1)  fault-tolerant  seourity  requires  the  use 
of  preventive  rather  than  corrective  redun¬ 
dancy,  ( 2 )  graceful  degradation  of  seourity  is 
fenible  under  a  particular  interpretation,  (3) 
secure  f ault-toleranoe  is  s  complicated 
problem  when  software  Implemented  fault- 
toleranoo  techniques  are  used  (as  in  MuTEAM), 
and  (4)  more  study  is  requir<  '. 
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If  MuTEAM  were  provided  with  a  truated 
operating  system  in  the  sense  of  the  DoD 
seourity  evaluation  oriterla  at  the  B  or  A 
division  level,  it  oould  implement  the  man¬ 
datory  and  discretionary  security  policies  by 
using  seourity  labels  on  subjeots  and  objects. 
However,  faults  can  affeot  the  security  func¬ 
tions  as  muoh  as  computational  functions.  If 
the  security  functions  were  made  fault- 
tolerant  by  using  preventive  redundancy  tech¬ 
niques,  the  OS  oould  be  regarded  as  truatvor- 
thy  even  in  the  presence  of  faults.  However, 
if  the  software  implemented  f ault-toleranoe 
technique  now  being  used  in  MuTEAM  were  ex¬ 
tended  to  also  cover  the  security  function, 
the  OS  oould  not  be  regarded  as  trustworthy  in 
the  event  of  faults.  The  prudent  aotion  would 
ha  then  to  run  the  system  as  if  it  had  an 
untrusted  operating  system. 
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ABSTRACT 

In  the  defense  and  intelligence  community,  exercising  the 
"need-to-know"  principle  minimizes  the  potential  damage  that  can 
be  done  by  a  compromised  individual.  This  is  identical  to  using 
the  least  privilege  principle  in  computer  systems  to  minimize  the 
damage  that  an  arrant  or  malicious  process  can  cause.  Current 
security  models  do  not  appear  to  permit  the  principle  of  least 
privilege  to  be  fully  implemented.  This  weakness  is  exploited  by 
a  large  class  of  trojan  horses  and  computer  viruses.  User 
definable  domains,  as  developed  in  this  paper,  allow  the  princi¬ 
ple  of  least  privilege  to  be  implemented  completely,  thus 
providing  users  with  significantly  greater  protection  against 
these  threats. 


BACKGROUND 

It  is  an  accepted  tenet  of  the  government 
and  industrial  community  that  information  may 
be  owned.  As  with  any  resource,  there  is  a 
desire  to  protect  information  from  theft. 
However,  protecting  information  is  very 
different  from  protecting  other  property 
because  information  has  special  properties. 
Information  has  value,  but  who  possesses  the 
information  direotly  affects  that  value. 

Also,  information  may  be  freely  duplicated  in 
an  undetectable  fashion. 

One  example  of  this  is  a  football  coach 
who  develops  a  game  plan.  He  desires  to 
communicate  this  plan,  his  property,  to  his 
players.  But  only  for  them  to  use  in  a  game  - 
-  not  to  tell  others.  The  coach  wants  to 
share  information  yet  retain  control  of  its 
distribution.  We  term  this  the  information 
security  problem. 

This  situation  also  occurs  in  computer 
systems.  When  a  user  runs  code  written  by 
someone  else,  he  desires  some,  assurance  that 
this  code  will  not  leak  information  it  is 
given.  This  is  the  confinement  problem  as 
described  by  Lampson  [LAMP  73]. 

Throughout  time,  people  have  struggled 
with  this  problem.  One  highly  successful, 
although  incomplete,  solution  to  the 
information  security  problem  is  the  military 
"need  to  know"  system,  under  this  system 
eaah  individual  is  given  only  that  informat¬ 
ion  considered  necessary  to  perform  his  part 
of  an  overall  mission.  One  goal  of  this 
system  is  minimizing  the  damage  that  can  be 
done  by  a  compromised  person. 


The  computer  analog  to  need  to  know  is 
the  principle  of  least  privilege.  Saltzer 
and  Schroeder  identified  the  least  privilege 
principle  as  a  key  design  principle  for 
protection  mechanisms.  [SALT  75]  When  the 
least  privilege  principle  is  fully  implemen¬ 
ted  each  process  possesses  the  minimum  aooess 
to  information  required  to  perform  its  task. 

Current  security  models  implement  the 
least  privilege  principle  by  a  process  having 
only  those  privileges  explicitly  granted  by 
the  system.  This  policy  creates  what  Denning 
refers  to  as  a  closed  environment.  He 
further  states 

Tha  principle  of  a  closed  environment 
is  to  give  each  process  no  more 
capabilities  than  it  needs  to  perform 
its  task.  The  normal  state  of 
affairs  is  completely  disjoint, 
isolated,  processes:  nothing  can  be 
shared  or  exchanged  among  processes 
except  by  explicit  arrangement,  all 
interactions  being  prohibited  unless 
expressly  allowed.  No  process  oan 
attempt  to  interfere  or  communicate, 
with  another  in  an  unexpected  way. 

Because  a  closed  environment  forces 
all  interactions  into  the  open  it  is 
possible  to  check  them  all  for 
consistency  and  validity  as  desired 
[DENN  76] . 


On  many  computers,  it  is  difficult  or 
impossible  to  know  beforehand  what  tasks  a 
user  will  perform.  Because  of  this,  users 
are  given  a  class  of  privileges  which  comply 
with  some  security  policy,  e.q.  [BELL  75] 
This  often  leaves  a  user  process  with  much 
more  privilege  than  needed. 


This  paper  proposes  that  the  user  be  given 
the  ability  to  further  regulate  the  privile¬ 
ges  his  processes  have-  This  creates  a 
system  of  attenuating  privileges  which  allows 
a  user  to  protect  himself  from  a  large  class 
of  trojan  horse  attacks. 

it  is  not  proposed  that  this  is 
revolutionary,  but  it  is  believed  to  be  a 
useful  solution  to  a  real  problem.  In 
dealing  with  some  security  problems,  the  use 
of  set  theory  and  Venn  diagrams  is  more 
concise  and  more  direct  than  conventional 
matrix  notation. 


TERMINOLOGY 

BASIC  SETS 


Let  X  be  the  set  of  all  users.* 

u^  is  an  element  of  X. 

s  be  the  set  of  all  subjects, 
sj  is  an  element  of  8. 

o  be  the  set  of  all  objects, 
oi  is  an  element  of  0. 

A  be  the  set  of  all  access  rights, 
ai  is  an  element  of  A. 

| X |  denote  the  cardinality  of  X. 

*We  reserve  the  use  of  u  for  user 

tuple  sets  later  in  this  section. 

Subjects  and  Objects  may  have  individual 
attributes  associated  with  them  (c.g. 
security  level,  ownership  links,  etc.). 

An  access  triple  is  defined  as  a  tuple  of 
the  form  (s^,  o^,  am) .  An  access  triple  is 
also  called  a  privilege.  To  perform  the 
access  described  by  an  access  triple  is  to 
exorcise  the  privilege. 

Let  M  be  the  set  of  all  access  triples. 

M  -  (S  x  0  x.  A) 


At  this  point  we  introduce  the  concept  of 
a  User. 

Definitions: 

A  User  is  a  human  being  who  is  utilizing 
the  resources  of  a  computer  system. 

A  Subject  is  a  process  on  a  computer  that 
performs  operations. 

A  user,  upon  logging  .into  a  system,  causes 
the  creation  of  a  process.  Through  input  to 
this  initial  process,  the  user  may  create 
other  processes  and  effect  changes  to  data  on 
the  system.  The  concept  of  these  subjects 
(processes) ,  acting  to  carry  out  the  wishes 
of  a  user,  is  expressed  in  a  many-to-one 
mapping  of  subjects  to  Users.  This  mapping 
partitions  the  set  s  into  equivalence 


classes.  If  uj.  is  the  image  of  Sj  under  this 
mapping,  then  we  state  that  sj  isJa  subject 
acting  ia  behalf  of  user  u^.  JThe  set  of  all 
subjects  acting  in  behalf  of  user  U£  is  the 
subject  set  of  u^,  denoted  Xj,. 

We  write 

phi: a  — >  x 

where  =  {  Sj  |  PUI(sj)  =  uj.  ). 

M  may  also  be  partitioned  into 
equivalence  classes  by  Subjects,  Objects,  and 
accesses. 

A  user  tuple  set  for  a  user  Uj_,  denoted 
U^,  is  defined 

Uj_  =  X  0  X  A. 

This  set  defines  all  privileges  which  may  be 
exercised  in  behalf  of  a  given  user. 

SECURITY  POLICIES 

Suppose  that  R  is  a  nonempty  subset  of  M. 
If  we  designate  tuples  in  K  secure  and  those 
in  not-R  nonsecure  then  R  constitutes  the 
instantiation  of  a  Security  Policy.  A  triple 
in  R  represents  a  speoifia  access  to  a 
specific  object  by  a  specific  subject  which 
is  considered  permissable,  hence  secure,  by 
the  security  policy  corresponding  to  R.  Thus 
if  M  has  cardinality  m,  there  are  2M  possible 
security  policies,  one  corresponding  to  each 
of  the  elements  of  the  power  net  of  M. 


COMBINATION  OF  SECURITY  POLICIES 

If  the  intersection  of  two  or  more  sets, 
Bi  and  B.:,  is  taken,  the  sot  produced 
designates  what  we  call  the  combined  security 
policy.  A  very  important  property  of  this 
operation  is  that  this  combination  of 
security  policies  may  only  eliminate  tuples 
from  the  secure  set;  combination  of  a  given 
security  policy  with  others  can  never 
compromise  (add  undesirable  access  triples 
to)  the  initial  or  any  subsequent  policy. 
Thus,  freely  combining  (intersecting) 
security  polices  yields  a  system  of 
attenuating  privilege. 


TRUST 

For  a  given  security  policy,  It, 
exercising  a  privilege  deemed  non-oecure 
requires  trust  with  respect  to  the  policy  R. 


LEAST  PRIVILEGE 

For  a  given  task  with  a  given  algorithm 
there  exist  a  minimal  set  of  access  triples 
required  to  accomplish  the  task.  This  is  the 
set  of  least  privilege  for  the  task  and  is 
denoted  LP[task] .  We  assume  two  different 
sets  of  access  triples  imply  two  different 
algorithms. 

If  LP[task]  is  contained  in  the  subject 
triple  set  of  subject  sa,  and  is  also 
contained  in  the  secure  set  of  R  then  the 
task  may  be  accomplished  by  sa  without  trust. 
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DOMAINS 

A  domain  with  respect  to  security  policy 
R  has  been  defined  as  the  list  of  objects 
that  may  be  accessed  by  an  entity  [SALT  75]. 
We  further  constrain  the  notion  by  defining  a 
domain  as  the  set  of  objects  that  may  be 
accessed  and  the  accesses  allowed  to  those 
objects.  In  the  set  notation  a  user  Uj_'s 
domain  with  respect  to  a  given  security 
policy  is  defined: 

Dj_  =  Domain  [U£]  =  U*  INTERSECT  R 


CURRENT  MODELS 

Current  security  models  usually  separate 
security  into  two  facets  mandatory  and 
discretionary.  The  mandatory  security  policy 
implements  restraints  required  by  system 
owners  to  protect  what  they  consider 
sensitive  information.  The  discretionary 
policy  implements  restraints  chosen  by  owners 
(in  the  computer  sense)  of  information  to 
satisfy  their  opinions  on  how  the  data  should 
be  protected.  Generally,  Access  Control 
Lists  (ACL's)  are  used  to  implement 
Discretionary  Access  Controls  (DAC's) . 

c’or  example,  in  the  Sell  and  LaPadula 
(BLP)  security  model,  the  mandatory  security 
policy  requires  that  (s|,  oj ,  a^)  satisfy  the 
simple  security  policy  and  the  *-property 
(read  star  property) .  The  discretionary 
policy  is  satisfied  if  and  only  if  the  access 
right  a  is  in  cell  (S,  o)  of  the 
discretionary  access  matrix.  Usually,  the 
accesses  listed  in  the  cell  are  wholly 
controlled  by  ths  owner  of  the  specific 
object,  and  are  thus  ACLs.  Therefore,  the 
secure  set  can  be  viewed  as  the  intersection 
of  three  seta  Bj_,  B2,  and  B3  which 
correspond  to  security  policies  satisfying 
simple  security,  *-property,  and  the  access 
control  lists  respectively. 

More  generally,  a  security  policy  (-.p) 
embodied  by  n  properties  is  defined  as 

n 

Bsp  -  INTERSECT  Bj 


where  Bj  is  the  set  of  access  triples 
satisfying  the  i-th  property.  Figure  1  shows 
an  example  of  a  BLP  security  intersection. 


THE  PROBLEM 

EXCESS  PRIVILEGE 

Tha  partition  of  M  described  above  may 
also  be  viewed  from  a  user's  point  of  view. 
Intersecting  a  security  policy  with  a  user's 
tuple  set  defines  the  privileges  a  user  may 
exercise  without  trust,  his  domain.  Suppose 
ui  is  trying  to  accomplish  task  t.  Assume 
that  the  security  policy  is  Bap.  The  user's 
domain  is 


Di  “  Ui  INTERSECT  Bsp. 


We  assume  that  the  task  is  accomplishable 
without  trust, 


LP[t]  Di- 


This  allows  the  definition  of  the  set  of 
excess  privilege. 


EP[t,i]  -  Di  -  LP[t] . 


AN  EXAMPLE 

Given  a  world  with  three  objects  of 
interest,  (oj_,  o2,  o3) .  u3  owns  01?  U2  owns 
o2  and  o3.  The  security  policy  is  based  on 
the  BLP  model.  Assume  that  all  files  and 
subjects  are  operating  on  the  same  security 
level;  thus  the  mandatory  security  policy  is 
of  no  concern.  u3  and  u2  give  themselves 
the  right  to  road  and  write  their  own  files. 
However,  u2  also  gives  Ui  the  right  to  write 
to  his  file  o2  and  to  execute  the  program  03. 


BSp  =  {(<*1*  °l»  £)  /  (si,  o1(  it), 
(si,  o2,  w) ,  (s2,  o2,  £) , 
(s2,  o2,  it) ,  (s^  o3,  S) 
(s2,  o3,  £)  ). 

Ki  -  {  si  ). 

K2  -  {  S2  ) . 


Suppose  u2  tells  ul  that  03  is  a  great  game. 
Agreeing,  ul  causes  the  triple  (Si,  o3,  a)  to 
be  exorcised.  The  sat  of  least  privilege 
for  executing  o3  should  be 


LP[03]  -  ( (SX,  03,  X) ). 


However  the  domain  of  Ui  is 


Di  -  {(si,  ox,  r) ,  (si»  °i>  H) 1 

(Si,  o2,  w) ,  (s3,  o3,  X) ) • 


Thus , 

EP  -  ((slf  Oi,  r)  ,  (Si,  Oi,  Si), 

(Si,  o2,  H) ) 


In  addition  to  being  a  great  game,  the 
code  is  a  trojan  horse:  si  reads  0[  and 
writes  its  contents  into  o2  exploiting  the 
excess  privilege  (Si,  o2,  M) * 
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Note  that  (1)  an  undesired  information 
flow  w us  accomplished,  (2)  that  this  did  not 
involve  a  failure  of  the  security  mechanism 
but  exploited  a  weakness  in  the  security 
model,  and  (3)  that  this  flow  occurred 
without  the  knowledge  of  the  information's 
owner. 


THE  PROPOSED  SOLUTION 

In  the  above  example,  eliminating  either 
the  tuple  (sj,  o2,  a)  or  (s1#  o1(  £)  from  the 
set  Bgp,  would  prevent  the  compromise  of  the 
file  ox.  The  obvious  candidate  for  removal 
is  (sj ,  09,  a).  However,  by  the  hypothesis 
that  DAC  is  implemented  with  ACLs,  the  only 
user  that  can  remove  it  is  the  owner  of  o2 
which  is  u2.  Present  security  models  appear 
to  grant  the  owners  of  objects  absolute 
control  over  the  presence  of  tuples  involving 
these  objects  in  the  discretionary  aspect  of 
security  policy.  One  solution  to  this 
problem  is  grant  a  user  control  over  tuples 
involving  subjects  acting  in  behalf  of  that 
user.  This  control  is  granted  regardless  of 
the  object  to  which  a  tuple  refers. 

This  is  to  say  that  each  user  u j_  defines 
a  subset 

R(Ui)  <=  Ui 


which  m  deems  secure.  Thus  the  presence  of 
a  tuple 


( s j ,  ok,  a)  is  an  element  of  Rfu^) 

implies  that  user  u<  does  not  object  to  s-4, 
a  subject  authorized  to  act  in  behalf  of  U][, 
to  access  object  Ojj  in  the  fashion  described 
by  access  right  a.  This  is  wholly  in  the 
spirit  cf  discretionary  access  and  grants  the 
user  powers  denied  to  him  by  current 
policies.  This  subset,  a  security  policy,  we 
term  the  User  Definable  Domain  (UDD)  policy 
for  u^.  The  set  Rfu^)  is  the  domain  define 
by  user  uj  to  implement  more  completely  the 
least  privilege  principle  for  processes 
acting  in  his  behalf. 

Because 

Ui  INTERSECT  u j  =  { >  for  all  i  j , 


we  may  construct  the  union  of  all  these  sets 
without  permitting  users  to  interfere  with 
each  other.  This  set  w«*  term  BUDD  with 

1*1 

Budd  =  UNION  Ui- 
i=l 


Now 

bdac  =  b*cl  intersect  budd. 


IMPLEMENTATION  NOTES 

While  it  is  not  the  intent  of  this  paper  to 
address  implementation  questions,  a  few 
topics  should  be  addressed  to  show  the 
feasibility  of  this  model. 


COMPUTATIONAL  OVERHEAD 

The  overhead  of  this  scheme  could  be 
managed  by  maintaining  a  master  security 
matrix  s  x  o  x  A.  This  ties  the  overhead  of 
updating  security  sets  to  the  frequency  with 

which  users  update  their  domains  and  ACLs  — 
this  frequency  can  be  regulated  by  policy 
according  to  each  system's  needs.  An 
additional  advantage  of  this  scheme  is  that 
the  burden  of  updating  these  tables  can  be 
charged  directly  against  the  users  initiating 
the  update. 

Of  course  completely  maintaining  such  a 
matrix  is  not  practical  on  real  systems.  The 
size  of  the  matrix  would  overwhelm  the 
computing  power  of  some  machines  and  burden 
the  rest.  However  the  most  users  would  have 
sweeping  domains  where  all  members  of  a 
certain  group  are  excluded.  The  matrix  could 
be  factored  along  these  lines  and  only 
important  subsets  of  the  matrix  maintained 
dynamically. 


SECURING  REQUIRED  TABLES 

The  information  user  use  for  domain 
definition  needs  to  be  protected.  However, 
this  is  identical  to  the  problem  of  securing 
ACLs,  and  whatever  device  used  to  secure  ACLs 
should  be  able  to  protect  UDD  information. 


USER  INTERFACE 

The  model,  as  stated,  assumes  the  user 
has  a  fair  amount  of  knowledge  about  security 
and  operating  systems.  Since  this  is  not  the 
case  usually,  both  the  implementation  and 
administration  of  a  security  model  should 
address  the  problems  of  securing  the 
security-ignorant  and/or  computer- ignorant 
user. 

^  For  instance,  a  system  could  have  default 
domains  for  the  user,  user  groups  and  system 
functions.  Then  the  system  might  initially 
set  up  user  accessible  commands  (via  trusted 
path)  <trust>  and  <distrust>.  The  <trust> 
command  would  add  tuples  to  R(u) ?  the 
<distrust>  command  would  remove  them.  These 
utilities  would  allow  sophisticated  commands 
in  the  following  fashion: 

Strust  write  to  user**bruce 
( individual) 

$distrust  read  to  group-VLSI  DESIGN 
(group) 

$trust  read  to  directory-HOME 
(location) 
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User  defaults  would  be  set  up  by 
sophisticated  commands  to  protect  against 
standard  attacks  yet  allow  normal 
functioning. 

$trust  file_creation  to  directory-HOME  and  - 
owner-roe  and 
acl  -  none 

$trust  write  to  user-ME  and  directory-HOME  or 
directory-SYSTEM_TEMP_DIR 

This  family  of  commands  might  also  include 
hooks  into  the  DAC  system  so  that  a  user 
could  aay  "write  only  to  files  which  are  also 
not  readable  by  the  verification  group." 


VERIFICATION  ISSUES 

In  a  verified  system  that  maintains  a 
master  security  matrix,  we  believe  the  UDD 
system  can  be  retrofitted  to  provide  some 
level  of  assurance  by  verifying  two  things. 

As  a  scenario,  a  user  Uj  describes  to  a 
program  the  tuples  he  wishes  to  remove  from 
the  matrix.  This  program  generates  0,  a 
subset  of  M.  Next  a  process  requests  the 
operating  system  to  remove  0  from  the  master 
security  matrix,  R.  The  system  verifies  that 
this  request  originated  with  a  subject  acting 
in  behalf  of  Uj  and  does  the  following 
computation  (using  something  akin  to  Pascal} 

V  :=  V  INTERSECT  Uj  ; 

This  assures  that  the  user  is  removing  only 
his  own  tuples.  Next  the  system  updates  the 
master  security  matrix  by  computing 

R  R  -  V  ; 

At  a  minimum,  the  operations  of  validating 
the  identity  of  the  user  and  the  set 
operations  described  above  must  be  verified 
correct  and  then  made  tamperproof.  For  true 
security  though,  the  interface  which 
initially  generated  the  set  P  must  also 
undergo  verification. 


AN  EXTENSION 

Often,  an  individual  will  use  a  computer 
system  in  two  different  roles.  For  example 
in  a  small  software  design  team,  one  person 
might  be  both  a  programmer  and  an  archivist 
for  group  code.  The  domains  applicable  to 
these  two  tasks  are  likely  to  be  very 
different. 

To  account  for  this  need,  users  could 
also  have  more  than  one  domain,  R(u,k).  At 
process  creation  time  the  user  could  specify 
the  domain  to  be  used.  For  example  in  a  VMS 
system  the  command  could  be, 

$SPAWN/NOWAIT/SECURITYJDOMAIN«personnal  FUN 
payroll 

or  in  Unix  (if  wo  must) 

♦payroll  -sd  personnel  6 


CONCLUSION 

We  are  defining  security  policy  as  the 
intersection  sets.  We  enhance  current 
security  models  by  including  a  user-definable 
domain.  These  domains  allow  a  user  to 
constrain  information  flows  initiated  by 
subjects  acting  in  his  behalf.  We  have  for 
every  user  u^,  the  triple  (sj ,  Oj ,  &) ,  with 
sj  is  an  element  of  K^,  is  secure  with 
respect  to  u  if  and  only  if 

(si,  Oj,  a)  is  an  element  of  B^c  INTERSECT 
Bd.\C  INTERSECT  SUDD 

where  B^AC  is  the  set  of  triples  satisfying 
the  mandatory  access  constraints  of  the 
initial  model,  bACt  the  sets  of  triples 
satisfying  discretionary  access  constraints, 
and  Bm0d  is  the  sat  of  those  satisfying 
additional  conditions  devised  by  the  users  to 
closely  approximate  the  least  privilege  set 
required  for  their  processes. 

The  idea  of  protection  machanism  that  are 
subject  oriented  instead  of  object  oriented 
is  not  a  new  one [ DENN  82].  It  is  believed 
that  this  technique  can  be  used  to  enhance 
existing  models  in  an  efficient  (as  compared 
to  model's  initial  computational  overhead) 
manner,  that  the  additional  proofs  required 
for  verified  systems  will  be  manageable,  and 
that  it  will  provide  a  high  level  of 
assurance  against  discretionary  trojan  horses 
(including  computer  viruses). 
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A  =  Tuples  not  eliminated  by  *-property. 


B  =  Those  not  eliminated  by  the 
Simple  Security  Property. 


C  =  Those  not  eliminated  by 

Discretionary  Controls  (ACE's). 


In  the  User  Tuple  Set,  this  defines 
that  user's  DOMAIN. 


LP  *  The  set  of  beast  Privilege  for  seme  The  Set  of  Excess  Privilege  . 

task. 


FIGURE  1 

A  Vann  Diagram  Illustration  of  the  Concepts  Being  Discussed. 

(  Note:  in  the  fourth  figure  the  plane  set  switches  from  M  to  u^.) 
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INTRODUCTION  TO  THE  ACCESS  PATH 


flSIWg  THE  ACCESS  PATH 


TECHNICAL  DEVELOPMENTS 

Telecommunications  networks,  dispersed 
processing  capabilities,  increased 
storage  capacity  and  the  introduction  of 
software  components  with  advanced 
functions  have  totally  changed  the 
mainframe  computer  environment.  When 
data  processing  was  centralized,  the 
computer  and  all  terminals  were  located 
in  an  area  where  they  could  be  directly 
controlled.  Concerns  about  the  data  and 
the  computer  were  often  about  control 
over  physical  access  to  the  computer 
room  itself.  Computer  operators 
initiated  all  processing  and  loaded  all 
programs  and  data  files  as  needed. 

Output  was  reviewed  by  operations  and/or 
data  control  personnel  who  ensured  all 
jobs  were  processed  to  completion  and 
the  results  appeared  to  be  correct. 

They  then  released  the  output  to  the 
user  departments.  Many  of  these  systems 
were  relatively  simple-the  user  could 
often  review  and  reperform  the  computer 
generated  reports  to  determine  the 
correctness  of  processing. 

On-line  real-time  data  entry  with 
immediate  update  of  transactions  to  data 
files  has  removed  the  necessity  for  much 
of  the  batch  processing.  The  current 
level  of  sophistication  totally  removes 
the  operator  from  much  of  the  day-to-day 
control  over  the  processing.  Most  data 
files  and  programs  are  permanently 
resident  on  the  computer.  Operators 
cannot  identify  each  transaction  that  is 
processed,  nor  determine  its 
appropriateness  or  its  affect  on  each 
data  file.  The  possible  lack  of  hard 
copy  audit  trails  could  mean  the  user 
has  little  or  no  chance  to  retrospectly 
review  processing  in  its  entirety. 

The  risks  associated  with  data 
processing  have  increased  as  both  the 
speed  with  which  information  can  be 
changed  and  the  number  of  users 
accessing  the  system  have  rapidly 
increased.  Telecommunications  has 
vastly  expanded  the  number  of  terminals 
linked  into  the  mainframe  and  the  degree 
to  which  they  are  used.  The 
introduction  of  minicomputers  and 
microcomputers,  linked  both  to  each 
other  and  to  mainframes,  has  distributed 
processing  even  further.  These  new 
users  may  have  little  appreciation  for 
the  risks  of  data  loss,  error  or  fraud. 

The  traditional  control  features  such  as 
physical  access  and  division  of  duties 
can  potentially  be  compromised  in  these 
sophisticated  systems  by  any  person 
having  access  to  either  a  terminal  or 
another  computer  linked  to  the 
mainframe.  Management,  users  and  data 
processing  staff  all  need  to  place 
significant  reliance  on  the  appropriate 
functioning  of  the  computer  network  to 
reduce  the  risk  of  incorrect  or 
unauthorized  processing. 


People  unfamiliar  with  large  computers 
or  people  familiar  with  traditional 
batch  systems  may  find  that  identifying 
potential  risks  and  controls  in  the  maze 
of  software  components  which  make  up 
sophisticated  networked  computer  systems 
to  be  overwhelming.  A  simple  but  useful 
method  of  gaining  and  recording  an 
understanding  of  these  systems  is  to 
prepare  an  Accens  Path  diagram. 

An  Access  Path  diagram  is  a  concise  one- 
page  depiction  of  all  the  software 
components  in  the  system  under  review, 
and  depicts  the  sequence  of  information 
flow  from  one  component  to  the  next.  It 
is  a  very  useful  Instrument  when 
recording,  explaining  or  discussing  a 
system,  especially  for  identifying  the 
risks  and  controls  which  may  be  present. 


Figure  1 :  Access  Path  in  an  IBM  environnment 
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TELECOMMUNICATIONS 


RISKS  AND  CONTROL  CONSIDERATIONS 

Built  into  these  multiple  layers  of 
software  are  features  that  may  affect 
the  risk  and  control  considerations  such 
as  passwords,  user  identification  codes, 
transaction  codes,  access  level 
indicators  and  processing  options.  The 
same  software  components  can  be 
implemented  differently  in  every 
location.  For  example,  most  access 
security  software  packages  provide 
various  options  for  the  treatment  of 
unauthorized  access  attempts  it  could 
disallow  the  access  and  not  report  the 
violation;  it  could  disallow  the  access 
and  report  the  violation  for 
investigation;  it  could  allow  the  access 
and  report  the  violation;  it  could  allow 
the  access  and  display  a  warning  message 
to  the  user;  it  could  allow  the  access 
and  ignore  the  violation  completely. 

How  these  features  within  each  component 
are  installed  and  maintained 
significantly  affects  the  risks  and 
controls  present  in  each  system.  The 
Access  Path  shows  a  broad  view  of  the 
software  components  involved  and  where 
the  installation  may  have  used  the 
control  opportunities  available  in  each 
component.  If  an  in  depth  evaluation  of 
the  system  is  required,  more  detailed 
information  can  then  be  obtained  for 
those  software  components  identified  as 
being  relevant. 

DESCRIPTION  OF  THE  SOFTWARE  COMPONENTS 

Figure  2  illustrates  the  view  that  most 
users  have  of  their  data  access  -  an 
uninterrupted  direct  connection.  They 
generally  do  not  understand,  and  should 
not  have  to  understand,  all  the  software 
involved  in  accessing  the  data.  This 
section  will  give  a  brief  description  of 
the  actual  activities  that  take  place 
transparently  each  time  a  user  -  for 
example,  an  accounts  receivable  clerk  - 
accesses  data  in  a  typical  mainframe 
computer  installation. 


Flflui*  a.  Meat  uen  aa*  their  computer  oyatent  at  »hown.  They 
know  the  th#r*  ar*  terminal*  and  fit**  Involved,  thay  may  not 
(•allta  how  th*  Kia*  am  aocaaatd. 


The  first  component  of  system  software 
encountered  on  the  access  path  is  the 
Telecommunications  Software  (illustrated 
in  Figure  3).  This  software  connects 
all  the  terminals,  printers  and  other 
peripherals  to  the  rest  of  the  computer 
system.  All  of  these  links  need  to  be 
defined  within  the  telecommunication 
software  if  the  rest  of  the  system  is  to 
receive  messages  from  or  submit  messages 
to  any  of  these  peripherals. 

The  software  continuously  "listens"  to 
all  uhe  terminals  for  any  messages  being 
transmitted.  When  it  "hears"  a  message, 
it  identifies  the  terminal,  retrieves 
the  message  and  transmits  it  to  the 
system.  Likewise,  it  "hears"  and 
retrieves  messages  from  the  system  and 
transmits  them  to  the  terminals 
indicated. 

The  telecommunications  software  used  by 
most  IBM  mainframes  is  the  Virtual 
Telecommunications  Access  Method  (VTAM) . 
VTAM  is  made  up  of  several  different 
programs  which  essentially  perform  the 
following  functions: 

*  Recognize  that  a  terminal  is 
attempting  to  submit  a  message 

*  Identify  the  terminal  and  check  if 
it  is  defined  within  the 
telecommunication  software 

*  Ensure  the  access  authority,  as 
defined  within  the 
telecommunication  software,  is 
appropriate  for  the  intended 
message 

*  Package  and  transmit  the  message  to 
the  next  component  of  the  access 
path 

*  Recognize  that  a  message  is  being 
sent  from  the  system  to  a 
peripheral  and  route  it 
accordingly. 


-Uutaui. 


Main  from* 


VTAM 


rigur*  3  :  communication*  software  la  TKa  first  atep  In 
tha  aooaa*  modal.  For  th*  tyttem  to  *eo*p<  a  m***age 
from  a  terminal,  H  muat  b*  daflnad  to  th*  computer  via 
title  (ottwaiw.  At  thla  point,  th*  communication*  aoft- 
war*  provide*  th*  oomputer  with  th*  maaaag*  b*lng 
aant  a*  wall  a*  th*  Identification  (terminal)  trom  which 
th*  iwquoat  la  earning,  Communication*  aoftwara  can 
limit  th*  function*  that  oan  b*  parformad  by  th*  termin¬ 
al.  In  addition,  than*  may  b*  paaawerd  protection  avail¬ 
able. 
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TRANSACTION  PROCESSING  SOFTWARE 

The  second  component  of  system  software 
on  the  access  path  is  the  Transaction 
Processing  (TP)  software  (illustrated  in 
Figure  4) .  TP  software  is  used  by  many 
computer  installations  to  specify  which 
terminal  can  use  application  programs 
(exceptions  to  this  rule  are  the  Time 
Sharing  Option  (TSO)  and  other  text 
editors.  These  are  discussed  below. 

TP  software  serves  as  the  link  between 
the  telecommunication  software  and  the 
application  program  which  actually 
processes  the  message,  and  can  be  used 
with  both  batch  and  real-time  systems. 
The  message  transmitted  by  a  user 
contains  a  name  or  code  whereby  the  TP 
software  can  identify  its  nature.  The 
TP  software  then  performs  various 
control  functions  which  enable  the 
message  to  pass  along  to  the  required 
application  program  for  processing  if 
the  access  is  permitted  by  the  access 
tables  contained  within  the  TP  software. 

The  most  commonly  used  Transaction 
Processing  software  on  IBM  mainframes  is 
Customer  Information  Control  System 
(CICS) .  Information  Management 
System/Data  Communications  (IMS/DC)  is 
an  alternative  for  a  system  which  uses 
an  IMS  data-base  management  system. 

CICS  can  perform  many  functions,  but 
broadlv  described  it  performs  the 
following: 

*  Handles  all  terminal  messages 
transmitted  to  and  from  the 
Telecommunication  Software 
(described  in  the  previous  step) 

*  Schedules  the  execution  of  all 
processing  activity  within  CICS. 
Each  component  of  processing 
activity  is  called  a  task 

*  Controls  the  information  flow  to 
accommodate  multitasking.  This 
allows  more  than  one  task  to  be 
submitted  at  a  time,  although  only 
one  task  will  be  executing  at  any 
specific  point  in  time 

*  Controls  the  loading  and  releasing 
(unloading)  of  the  application 
programs  required  to  execute  the 
tasks. 

The  Timesharing  Option  TSO)  and  other 
text  editors  (WYLBUR,  ROSCOE,  et  al) 
were  designed  primarily  as  productivity 
aids  for  application  and  system 
programmers.  Use  of  these  editors  does 
not  tie  the  terminal  to  specific 
programs  as  does  CICS  and  other  TP 
software.  Rather,  the  editors  make 
utility  programs  available  which  allow 
programmers  to  read  files,  tables  and 
libraries;  scan  them;  change  them  and/or 
delete  them.  In  addition,  the  editors 
allow  submission  batch  jobs  that  are 
handled  by  the  system  like  any 
production  job. 

Figure  5  shows  the  power  that  editors 
such  as  TSO  give  the  programming  staff. 
In  essence,  all  files,  programs  and 
tables  are  potentially  available  to  the 
user  of  such  an  editor. 


Figure  4  :  Transaction  processing  software  cun  be  used 
to  limit  acoosa  to  tho  ayatem  by  matching  apaciflo  trans¬ 
action*  to  tha  terminals  and/or  user*.  Linn  I  tod  password 
security  measures  can  alto  ba  Implemented  haro. 

Log  fllaa  can  ba  produoed  that  can  ba  uaad  for  backup/ 
reoovery  purpoooo  aa  wall  aa  to  datarmlna  (audit)  ays* 
tom  usage. 


UTILITIES  | 


IrtERWKXMAMMER  AREA 


DATA 


Flgura  8  ;  In  many  data  prooaaalng  departments,  tha  ays* 

tame  and  appllcationa  programmer#  hava  acoaaa  to  utllltlaa 
that  allow  thorn  to  add,  delate  and/or  change  program* 
and  data  fllaa.  Dua  to  tha  eapabilltiaa  of  tha  utilities,  dose 
aupaivlslon  and  ravlaw  of  thrir  ua*  may  ba  naoasaary. 
Additionally,  care  should  ba  taken  relating  to  any  “ua er“ 
activity  that  ptogrammwe  era  allowed  to  perform. 
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After  the  TP  software  has  identified  the 
nature  of  the  message  and  completed  the 
necessary  control  functions,  it 
transmits  the  message  to  the  relevant 
application  program.  This  is  the 
program  that  will  perform  the  actual 
function  required  by  the  user,  for 
example:  do  a  calculation,  search  for 
the  available  quantity  of  an  inventory 
item,  or  print  an  invoice.  Whereas  one 
Telecommunication  Software  package  and 
one  Transaction  Processing  Software 
package  normally  handle  all  the 
information  flowing  within  a  given 
access  path,  there  may  be  tens,  hundreds 
and  even  thousands  of  application 
programs  which  can  be  used  within  the 
same  access  path. 

Many  organizations  are  now  purchasing 
and  installing  application  programs  for 
common  business  systems  which  have  been 
developed  by  independent  software 
vendors  rather  than  employing  their  own 
programmers  to  develop  the  applications. 
This  purahased  software  is  also  referred 
to  as  "packaged"  or  "off-the-shelf" 
software,  and  although  it  is  most  often 
associated  with  microcomputers  there  are 
numerous  vendors  selling  application 
software  for  mainframes.  Figure  6 
illustrates  the  Application  Program  in 
the  Access  Path. 

Application  programs  are  written  in  a 
variety  of  programming  languages.  The 
majority  of  business  application 
programs  are  written  in  COBOL. 


Flgup*  *  ;  At  till*  (rtlnt  tlw  application  program*  an  ae- 
caaaad.  Th*  program  analyxaa  th*  data  raoalvad  to  da  tor¬ 
mina  how  th*  tranaactlon  ahould  ba  prooaaaad  and  raeerdad 
on  th*  til**.  Editing,  raaaonabianat*  chock*,  *to.  can  ba 
iwi  format)  hoc*.  In  addition,  tha  program  may  raad  and 
write  to  III**,  format  and  aand  maaaagaa  to  th*  originating 
tamilnol  and  can  parte rm  additional  aaeority  ratatad  func¬ 
tion*. 

Kany  application  aottwar*  packages  can  b*  purchased  from 
third-party  vendor*.  Th*  uatr  of  purchased  aottwar*  ahould 
on  aura  that  th*  aottwar*  maaia  tholr  naada. 


Almost  all  application  programs  require 
the  manipulation  of  data  in  some  manner. 
Data  may  be  read,  added,  deleted  or 
changed.  Data  is  stored  in  files  which 
may  be  on  magnetic  disk  or  tape.  • 
Although  the  application  programs  issue 
the  instructions  directing  the  ’ 
manipulation,  it  is  the  Fils  Access 
software  that  actually'  retrieves  the 
data  from  and  writes  the  data  to  the 
files.  In  data  processing  terminology, 
these  manipulations  are  referred  to  as 
tha  input/ output  (I/O)  operations. 

Thera  are  many  different  file  access 
methods.  Two  of  the  most  commonly  used 
are  Indexed  Sequential  Access  Method 
(ISAM)  and  Virtual  storage  Access  Method 
(VSAM) .  Figure  7  illustrates  the  File 
Access  method  in  the  Access  Path. 


Where  an  installation  uses  a  data  base 

rather  than  conventional  computer  files 

for  storing  data,  there  is  an  additional 
component  In  the  access  path.  The 
storage  and  organization  is 
by  a  Data  Base  Management  System  (DBMS) . 
Two  of  the  most  frequently  used  data 
base  management  systems  on  IBM 
mainframes  are  information  Management 
system  (IMS)  and  Integrated  Data  Base 
Management  system  (IDMS) .  Any  data 
access  has  to  pass  through  the  DBMS  to 
obtain  the  exact  storage  location  of 
such  data.  Within  the  DBMS  a  File 
Access  method  performs  the  actual 
input/output  operations.  These 
components  are  illustrated  in  Figure  s. 
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OPERATING  SYSTEM 

The  operating  System  is  an  integrated 
set.  of  programs  that  control  and 
coordinate  the  operation  of  the 
computer.  It  interacts  with  all  the 
previously  mentioned  steps  in  the  Access 
Path  and  allows  all  the  components  to 
communicate  with  each  other.  Part  of 
the  system  software,  it  is  a  set  of 
programs  that  directs  the  computer 
system.  It  can  translate  high-level 
languages  (e.g. ,  COBOL)  into  machine 
language  (with  a  compiler) ,  manage 
system  resources  (tape  and  disk  files, 

?rog ram  libraries,  etc.),  retrieve 
nformation  from  files,  schedule  and 
supervise  work,  and  operate  and  control 
mechanised  devices  (tape  and  disk 
drives,  computer  terminals,  etc.).  It 
is  not  specific  to  any  one  application, 
but  may  be  used  in  the  design, 
processing  and  control  of  all 
applications  and  other  system  software 
components . 

The  Operating  System  provides  the 
operators  control  over  starting  up  and 
shutting  down  the  computer,  and  controls 
the  allocation  of  resources  to  enable 
the  computer  to  process  efficiently  and 
handle  multiple  users  accessing  the 
system  at  the  same  time.  Figure  9  shows 
the  operating  system  as  part  of  the 
Access  Path.  All  activity  within  the 
shaded  area  occurs  under  the  control  of 
the  operating  system. 


There  are  two  basic  operating  systems 
used  on  IBM  mainframes.  The  earliest 
system,  introduced  in  the  1960's,  is  the 
Disk  Operating  System  (known  as 
DOS/VSE) .  The  later  system,  introduced 
in  the  mid-1970's,  is  Multiple  Virtual 
Storage  (known  as  OS/MVS) .  Although  the 
two  systems  perform  similar  functions, 
there  are  many  differences  between  them, 
and  switching  a  computer  from  one  system 
to  the  other  requires  a  major  effort. 


Figure  ».  Tho  operating  ey itom  oottwor#  ho*  control 
tvor  oil  th*  provlouoly  mentioned  “otop*  .  8lnc*  there 
oon  bo  mony  uoor*  on  th*  oyotom  «t  th#  oam#  tlmo, 
“traffic  oontrol”  la  nooooooiy  to  glv*  proooMlng  time 
to  oooh  took.  Th*  oporotlng  oyotom  ochodulo*  oooh 
teak  to  anaura  that  oooh  uoor  lo  glvon  appropriate 
priority  and  th#  correct  roaouroo*  tor  th*  job 

/III**  iflab  Hiluat. 


ACCESS  CONTROL  SOFTWA5E 

As  computer  systems  have  become  more 
sophisticated,  the  number  of  users, 
transactions  and  software  components 
have  increased.  In  order  to  limit  the 
access  each  user  has  within  the  system  a 
number  of  Access  Control  software 
packages  have  been  developed.  Tnese 
packages  are  designed  to  protect  the 
data  files,  program  files  and  system 
software  files  within  the  installation 
considered  to  be  vulnerable* 
accesses  permitted  within  the  system J  ate 
defined  in  access  tables,  and  the  system 
then  compares  every  action  attempted 
against  these  tables  to  determine  if  the 
action  will  be  permitted.  Obviously 
these  systems  are  only  ef£°°£^e 
access  rules  defined  In  the  tables  aro 
functionally  appropriate,  correctly 
implemented  and  accurately  maintained. 
Figure  10  illustrates  the  access  control 
software  operating  within  the  access 
path. 
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The  three  most  frequently  used  access 
control  packages  on  IBM  mainframes  are 
RACF,  (an  IBM  developed  package)  and  two 
independently  developed  packages,  ACF2 
and  Top  Secret. 


Flgur*  10.  Aooui  control  (ottworo  con  bo  uood  to  limit 
oooooo  to  (Hoc,  llbrorlos  ond  tobloo  hold  on  tho  computer. 
Tito  proper  Implomontotlon  of  ouch  oottwora  con  jld  In 
providing  o  ooooro  oyotom.  Ongoing  monitoring  ol  tho 
oyotom  lo  roqulnd  to  on  euro  thot  tho  ooourlty  pollcloo 
ond  proooduroo  oro  lollowod. 


■THE  AUDIT  AND  REVIEW  OF  THE  ASSESS  M 

The  access  path  is  a  methodology 
developed  to  help  the  auditor  define  and 
evaluate  system  security  and  other 
restrictions  against  unauthorized  access 
in  a  complex  environment,  it  is  an  easy 
way  to  understand  system  and  application 
software  interaction.  An  auditor  needs 
to  know:  who  can  access  what  data  files? 
The  Access  Path  provides  him  a  way  of 
identifying  every  possible  way  of 
accessing  one  file.  Each  way  is  a 
different  access  path. 

Thus,  the  first  step  in  the  audit  or 
review  process  is  to  identify  the  files 
or  data  elements  which  are  of  interest 
to  the  auditor. 


Every  access  path  to  these  sensitive 
files  should  then  be  mapped.  Most 
installations  have  several  access  paths 
to  the  data  files.  The  path  can  be  the 
batch  processing  of  production  jobs,  on 
line  access  by  the  user  department,  use 
of  utility  programs  by  application 
programmers,  etc.  Every  path  will  be 
made  up  of  different  kinds  of  software. 
Access  to  data  is  controlled  by, these 
different  layers  of  system  software  and 
application  programs.  At  eaoh  layer, 
there  may  be  controls  that  prevent 
system  users  from  performing  tasks 
outside  of  management's  intentions  (see 
Figure  11) .  How  these  controls  are 
actually  employed  is  an  audit  concern. 


available  to  tho  poroonnoi  roeponalbl#  for  tho 
design  of  tho  oyotom  ond  oomputor  network. 

Tho  auditor  should  understand  tho  toohnology  so 
impleinontod  within  tho  dots  corner,  recognize  tho 
methodology  bo!.ig  uood  ond  Incorporate  it  Into 
tho  audit  plan. 


The  auditor  will  review  as  part  of  the 
audit,  the  security  features  for  each 
software  mapped  on  a  path  giving  an 
access  to  any  sensitive  data  files.  The 
auditor,  or  reviewer,  knowing  the 
control  opportunities  which  each 
software  product  offors,  will  record, 
for  all  these  software  products,  which 
of  those  opportunities  have  been 
implemented . 

For  example,  the  security  key  feature  of 
C1CS  might  be  employed  to  restrict 
access  to  CICS  transactions.  The  result 
of  these  inquiries  provide  a  map  of  the 
Access  Path,  with  the  implemented 
controls  which  restrict  access  and 
therefore  indicate  the  areas  which  merit 
testing.  The  testing,  in  this  case, 
will  involve  the  review  of  the  user 
profiles  and  tables  which  the  relevant 
software  products  reference  in  order  to 
restrict  access.  This  review  will 
typically  have  to  be  conducted  with  the 
use  of  software  for  the  purposes  of 
printing  out  the  profiles  or  tables. 

This  software  may  be  a  feature  of  the 
product  itself,  a  general  purpose 
utility  program  which  is  supplied  by  the 
vendor  or  a  software  product  expressly 
designed  for  this  purpose.  Coopers  & 
Lybrand  has  developed,  and  continues  tc 
develop,  customized  software  for  this 
purpose  (i.e.  the  C1CS  Analyzer). 

Having  reviewed  those  profiles  for  the 
users  and  reached  an  opinion  as  to  their 
adequacy,  the  next  step  is  to  aonsider 
and  review  the  paths  which  oan  be  taken 
by  other  categories  of  user.  It  is  also 
important  to  remember  that  the  tables 
and  profiles  which  have  been  reviewed 
above  will  be  the  subject  of 
maintenance.  This  is  because  the 
community  of  users  is  normally 
constantly  changing  as  a  result  of 
employees  joining  and  leaving  the 
company  as  well  as  transfers  from  one 
department  to  another.  Also,  it  should 
be  remembered  that  the  application 
programs  and  system  software  products 
are  also  being  changed.  Therefore,  it 
is  important  for  the  access  paths  to  the 
tables  and  profiles  be  mapped  and  a 
review  be  conducted  of  the  adequacy  of 
the  controls  over  this  change  management 
process. 


In  order  for  this  review  to  be  complete, 
it  is  important  to  consider  all 
categories  of  user  who  potentially  might 
have  access  to  the  data  and  programs  and 
profiles  or  tables.  In  the  steps  above, 
we  have  reviewed  the  end-user  and  those 
who  ara  responsible  for  maintaining  the 
profiles  and  tables.  It  is  also 
neoessary  to  review  the  access  paths 
that  the  members  of  the  Data  Processing 
Department  use.  Obviously,  when 
reviewing  the  Access  Paths  that  are 
mentioned  above,  the  main  purpose  is  to 
ensure  that  only  authorized  users  have 
access  to  authorized  facilities.  One 
detailed  aspect  of  this  would  be  to 
ensure  that  members  of  tha  Data 
processing  Department  do  not  have  access 
to  production  versions  data1  files  using 
production  versions  of  programs. 

Members  of  the  programming  section  of  a 
data  processing  department  will 
typically  have  access,  via  the  system, 
to  various  operating  system  utility 
programs,  typically  via  an  editor  suoh 
as  TSO,  for  example.  They  will  also 
have  tha  ability  to  submit  batch  jobs 
for  processing.  It  is  with  these 
programming  tools  that  they  could  gain 
access  to  lino  or  production  versions  of 
programs  and  data  files,  thereby 
bypassing  controls  which  are  contained 
not  only  in  the  application  programs  but 
also  in  tha  system  software  components. 
It  should  be  remembered  that  these 
"bypasses"  must  exist  in  most 
installations  for  valid  operational 
reasons.  For  example,  the  database  may 
require  repairing  after  the  computer 
went  down  because  of  a  power  failure  or 
a  logic  error  in  a  program.  Tha 
essential  consideration  here,  though,  is 
to  ensure  that  the  use  of  these  access 
paths  is  suitably  restricted  and 
authorized.  This  review  will  involve 
using  software  to  print  out  reports 
showing  the  user  profiles  in  the  editor 
(e.g.  TSO)  and  considering  the 
appropriateness  of  the  entitlements 
given  to  each  user. 

After  having  identified  the  active 
security  features  within  all  software 
layers  of  every  possible  path  to 
sensitive  data  files,  the  auditor  is  now 
in  a  position  to  evaluate  the  risk  of 
unauthorized  access  to  these  files. 
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Abstract 

Specific  problems  which  currently  limit  the 
effectiveness  of  computer  security  risk 
analysis  are  discussed.  These  problems  have 
already  surfaced  and  in  some  cases  been 
addressed  by  the  risk  analysis  community 
outside  of  computer  security.  It  appears 
that  the  quality  of  computer  security  risk 
analysis  can  be  significantly  improved  by 
using  previous  work  or  undertaking  certain 
basic  steps  in  these  areas. 

1.  INTRODUCTION 

In  recent  years,  significant  changes  have 
taken  place  in  the  computer  security  field. 
With  the  explosive  growth  of  personal 
computing,  computer  system  penetration  from 
home  is  now  a  reality  which  is  constantly 
demonstrated  [Park83].  In  response,  port 
protection  security  devices  have  been 
developed.  New  products  have  come  to  market 
(and  continue  to)  in  other  areas  of  computer 
security  as  well;  over  a  hundred  were 
exhibited  at  one  recent  trade  show. 

Work  in  traditional  areas  of  computer 
security  research  (e.g.,  authentication 
methods,  cryptography,  statistical  inference 
protection)  continues  [ProcBb],  especially 
research  into  the  development  of  trusted 
operating  systems  for  multilevel  secure 
operation  (spurred  on  by  truslud  system 
evaluation  criteria  [NCSC83]),  However, 
with  the  increased  realization  that  mo-'' 
computer  security  problems  and  solutions  are 
not  entirely  technical,  and  with  the 
increasing  number  of  real-world  systems  at 
risk,  the  risk  analysis  process  has  lately 
received  additional  attention  [Cecu86, 
Guar85,  Hoff85]. 

While  risk  analysis  is  an  interdisciplinary 
area,  computer  security  specialists  have  in 
general  not  used  models  and  techniques  from 
other  fields  to  the  extent  possible.  There 
has  been  some  cultural  gaps  between  the  risk 
analysis  community  which  has  been  developing 
models  and  techniques  for  risk  assessment 
and  risk  management  and  the  computer 
security  community  which  has  until  recently 
largely  concentrated  on  either  technical  or 
administrative  solutions  without  paying  a 
great  deal  of  attention  to  exposure 
assessment,  risk  characterization  (including 
uncertainty),  or  weighing  of  alternative 
solutions . 

This  is  not  surprising  since  risk  analysis 
(like  computer  security)  is  a 
multidisciplinary  field  requiring  a  blend  of 
skills:  the  development  of  any  such  field 
must  cross  disciplinary  boundaries  and 
breach  semantic  barriers.  Few  in  the 
computer  security  community  know  of  existing 
results  in  probabilistic  risk  analysis  or 
even  of  the  existence  of  the  Society  for 
Risk  Analysis  or  its  journal;  similarly, 


very  few  risk  analysts  have  paid  any 
attention  to  the  computer  security 
literature.  And  this  type  of  work,  like  any 
which  crosses  jurisdictional  boundaries,  has 
trouble  attracting  support  from  traditional 
sponsoring  organizations  or  universities. 

Unlike  traditional  risk  analyses  which  deal 
with  concete  consequences  (such  as  money  or 
lives  lost),  often  computer  security 
concerns  are  diffuse  and  intangible  (e.g., 
military  advantage,  competitive  advantage, 
privacy  protection).  Asset  values  are 
more  difficult  to  arrive  at,  since  data  can 
be  an  ambiguous  asset  whose  value  varies 
significantly  over  time  and  by  use.  And 
perhaps  more  so  than  in  other  areas, 
operational  priorities  put  real-world 
constraints  on  what  computer  security 
measures  will  be  used.  Still,  the  existing 
risk  analysis  literature  may  be  able  to  shed 
light  on  ttie  costs  of  breached  security. 

In  the  past,  the  computer  security  community 
has  often  used  ill-fitting  adaptations  of 
risk  analysis  methods  that  were  developed 
for  problems  which  were  significantly 
different.  The  majority  of  computer 
security  risk  analyses  have  used  annual  loss 
expectancies  (Al.Es),  a  method  well-suited  to 
and  used  by  insurance  companies.  However, 
unlike  insurance  risks,  computer  security 
risks  often  are  multiple  and  not  readily 
specified  (by  money,  injury,  or  death). 
Often  the  potential  losses  are 
intangible — related  to  national  defense, 
corporate  goodwill,  or  other  nonmonetary 
assets.  Unlike  traditional  risk  analysis 
problems,  computer  security  problems  tend  to 
often  lie  in  a  relatively  uncharted  area, 
thut  of  diffuse  risks  from  adversarial 
sources,  where  the  objects  at  risk  and  the 
nature  of  the  risk  may  be  diffuse  and  where 
the  source  of  the  risk  may  be  a  malevolent 
adversary.  These  risks  might  be 
characterized  as  points  on  the  right  of 
Figure  1  [ Brow86  ] . 


Figure  1,  Categorization  di  Rlak  Analysia  Problaoj 
by  Type  and  Source  oC  Risk  (Brov06) 
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2.  MAJOR  PROBLEMS  IN 
COMPUTER  SECURITY  RISK  ANALYSIS 

There  are  several  areas  where  significant 
problems  exist  which  currently  limit  the 
effectiveness  of  computer  security  risk 
analysis.  The  problems  appear  to  be 
tractable;  by  bringing  resources  to  bear  on 
them,  the  quality  of  computer  security  risk 
analysis  can  be  significantly  improved. 
This  section  describes  the  specific  areas 
and  suggests  appropriate  actions  to  take. 

2.1.  Semantic  Problems  Due  to  a  Lack  of 
Standard  Definitions 

A  critical  area  where  research  i3  needed  is 
that  of  standard  definitions  in  risk 
analysis  for  computer  security.  While  there 
are  accepted  terms  in  both  fields,  sometimes 
the  same  term  means  two  different  things, 
depending  on  the  field;  in  some  cases,  there 
are  differences  among  workers  even  in 
computer  security;  in  a  few  cases,  there  are 
out  and  out  conflicts  between  the  commonly 
accepted  definitions  in  risk  analysis  and 
usage  in  computer  security.  Ey  and  large 
however,  these  conflicts  appear  resolvable 
if  addressed  promptly;  both  fields  are 
relatively  new  and  the  leaders  appear  quite 
willing  to  work  together  to  agree  on  one 
common  set  of  terms. 

There  is  a  computer  security  glossary 
produced  by  the  National  Bureau  of  Standards 
which  contains  several  hundred  definitions 
which  has  been  out  for  several  years;  a  more 
recent  one  is  [NCSC85]  from  the  National 
Computer  Security  Center.  Even  so,  in  the 
workshop  which  led  to  this  paper  [Hoff86], 
"we  had  significant  trouble  with 
communication  among  computer  security 
people"  [Cour85].  There  does  not  appear  to 
be  any  widely  used  formal  glossary  of  terms 
for  the  risk  anulysis  field  in  general.  It 
is  absolutely  necessary  that  the  two 
disciplines  communicate  well;  therefore, 
harmonization  of  existing  definitions  is 
needed  and  a  common  glossary  of  terms  would 
be  helpful. 

2.2.  Absence  of  Guidelines  on  When  to  Use 
Risk  Analysis 

Another  Important  issue  is  when  to  use  risk 
analysis.  Too  often  in  the  past,  computer 
security  practitioners  have  either  avoided 
initiating  a  risk  analysis  due  in  part  to 
fear  of  its  cost  or,  alternatively, 
initiated  full-fledged  analyses  which 
slavishly  used  methodologies  better  suited 
for  other  problems  and,  as  a  result,  cost 
more  and  produced  less  of  value  than 
desirable  and  possible.  Apparently  no 
guidelines  exist  regarding  whan  a  risk 
analysis  or  a  specific  methodology  should  be 
initiated  or  terminated. 

It  is  inappropriate  to  use  (certain  kinds 
of)  risk  analysis  when  the  potential  benefit 
gained  from  such  use  is  too  small.  A 
related  issue  is  how  far  to  go;  one  may 
often  need  a  relatively  simple  or  even 
cursory  analysis  and  nothing  more. 
Alternatively,  one  may  begin  an  analysis, 
suspend  it  for  a  time,  and  then  resume  it  as 
events  warrant.  Finally,  in  some  cases  a 


full-blown  exhaustive  analysis  may  be  called 
for. 

As  an  example,  often  safeguards  which  cost 
the  least  displace  the  most  risk; 
organizational  policy  statements  and 
employee  awareness  programs  can  be 
relatively  easy  to  cost- justify ,  and  may  in 
many  cases  obviate  the  need  for  more 
detailed  risk  analyses.  But  the  problem  is 
not  always  that  simple,  and  in  particular 
safeguard  selection  can  be  complex: 

..."A  baseline  look  might,  at  times,  let 
you  identify  generic  measures  which 
should  be  taken  -  but  you  cannot 
implement  generics;  you  must  implement 
specifics.  To  identify  the  specific 
measures  needed  you  need  to  look  in  far 
greater  detail  than  is  normally 
considered  in  some  initial,  cursory 
inspection  and  understand  the  need  for  a 
set  of  fully  complementary  measures." 

[ Cour85 ] 

2.3.  Communicating  risk  management  options 
to  decision  makers 

Public  perception  of  computer  security 
breaches  often  involves  "hackers"  dialing  in 
from  afar  to  obtain  protected  information  or 
to  "crash"  a  system  [Levy84,  PaycBO]. 

However,  the  reality  is  that  outsiders  are 
much  less  likely  to  cause  computer  problems 
than  are  data  errors  and  omissions,  , 
dishonest  or  disgruntled  employees,  a| 
failure  of  administrative  controls,  or  water  i 
damage.  This  is  often  not  communicated 
effectively  by  computer  security 

professionals  to  their  management.  We  thus 
have  the  real-world  problem  of  the  risk 
analysis  that,  once  done,  sits  unread  upon  a 
shelf.  This  is  often  the  case  even  when  the 
results  are  appropriate  and  accurate  and  the 
analysis  was  done  efficiently.  Typically 
this  happens  because  top  management  was  not 
convinced  of  the  need  to  take  any  corrective 
action.  Often,  management  reacts  to  events 
rather  than  planning  protective  measures  in 
advance.  What  may  appear  reasonable  to  a 
security  manager  may  be  excessive  when 
looked  at  through  the  eyes  of  a  higher  level 
decision  maker. 

Indeed,  one  of  the  most  vexing  problems  risk 
analysts  and  computer  security  experts  have 
is  communicating  risk  management  options  to 
decision  makers.  Risks  and  adverse  events 
are  often  not  popular  topics,  and  the 
options  available  may  all  be  undesirable. 
Presenters  of  risk  management  options  have 
to  avoid  a  number  of  pitfalls.  On  the  one 
hand,  they  may  be  accused  of  being  too 
analytical  and  cost-oriented  and  insensitive 
to  human  or  political  costs  which  are 
difficult  to  quantify;  on  the  other  hand, 
addressing  those  important  issues  but  not 
having  enough  credible  data  on  which  to  base 
a  decision  lays  them  open  to  charges  of 
being  vague.  Insensitivity  to  either  of 
these  can  spell  doom  to  any  hope  of 
selecting  reasonable  options  even  if 
excellent  data  is  in  hand  (which  is  never 
the  case).  Ignoring  interdependencies  may 
also  lead  to  unrealistic  risk  assessments 
and  thus,  when  discovered,  cripple  the 
credibility  cf  an  analysis.  Misapplication 
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of  automated  tools  and  unwarranted  belief  in 
their  output  is  another  potential  problem. 
And  of  course  no  methodology  will  be  useful 
in  an  institution  that  doesn't  want  to  know 
what  the  ri3ks  are;  it  takes  an 
organizational  commitment  to  make  the 
results  at  all  useful  [MacG86], 

Disciplines  which  are,  at  the  first  glance, 
far  removed  from  scientific  risk  analysis  — 
advertising,  communications,  psychology, 
etc.  —  might  contribute  to  better 
communicating  risk  management  information 
and  choices,  especially  since  there  so  may 
opportunities  for  misinterpreation  of 
results  as  diverse  audiences  are  addressed. 
The  area  is  so  new  that  the  first  major 
national  conference  on  communicating  risk  to 
the  public  took  place  in  January  1986  (the 
National  Conference  on  Risk  Communication, 
Mayflower  Hotel,  Washington,  D,  C.,  January 
29-31,  1986,  sponsored  by  The  Conservation 
Foundation,  National  Science  Foundation, 
Environmental  Protection  Agency,  American 
Industrial  Health  Council,  and  the 
University  of  Southern  California).  Efforts 
to  improve  this  situation  may  go  farther 
than  anything  else  to  mitigate,  in  the  long 
run,  the  real  problems  risk  analysts  are 
asked  to  addreas. 

2.4.  Lack  of  Teat  Beds  and  Respected, 
Available  Studies 

There  is  a  critical  lack  of  test  beds  and  of 
well-known,  respected  impartial  risk 
analyses  of  computer  system  security  to  use 
as  examples .  It  is  difficult  to  evaluate 
the  performance  of  various  risk  analysis 
methodologies  or  tools  without  a  suitably 
rich  test  bed.  With  one  or  two  exceptions, 
such  a  research  asset  does  not  exist  and  the 
fields'  growth  and  maturity  is  hindered  by 
incomplete  testing  and  information. 

In  test  bed  development,  as  in  real  world 
risk  analyses,  there  is  very  little  case 
data  available  on  which  to  base  estimates  or 
assessments;  and  computer  security  personnel 
have  long  bemoaned  the  fact  that  estimates 
of  threats  are  hard  to  elicit  and  very  hard 
to  justify;  there  is  not  enough  historical 
data.  Thus,  a  few  test  beds  and  pilot 
studies  which  incorporated  traditional  risk 
analysis  techniques  with  real  problems  from 
computer  security  (and  other  application 
areas)  and  using  real  data  would  be  very 
important  in  advancing  research  progress  by 
helping  us  to  develop,  based  on  real  world 
experience,  a  general  model  and  conceptual 
framework  for  computer  security  risk 
analysis.  Notions  of  generalization, 
methodological  development,  and 
demonstration  should  be  in  mind,  while  at 
the  same  time  carefully  focusing  the 
efforts.  The  scope  must  be  narrow  enough  to 
be  manageable;  one  would  hope  that  at  the 
end  the  result  could  be  a  highly  visible 
successful  application  of  known  techniques 
and  models  to  a  real  computer  security 
problem.  After  that,  other  efforts  can  be 
held  up  to  that  standard. 

2.5.  Problems  with  available  data 

In  any  undertaking  such  as  test  bed 
development,  data  base  problems  will  be  run 


into.  The  most  likely  of  these  is  lack  of 
data.  Risk  analysis  and  computer  security 
experts  have  long  bemoaned  the  fact  that 
there  is  very  little  real-world  case  data 
available  on  which  to  base  estimates  or 
assessments.  Real  world  case  data 
collection  would  help  matters,  both  in  the 
general  risk  analysis  case  and  in  the 
specific  computer  security  case.  Examples 
of  such  data  are  the  relative  frequencies  of 
different  types  of  security  breach  and  the 
measurable  impact  on  security  of  specific 
incidents  and  of  various  ri3k  management 
measures . 

Elicitation  of  this  information  is  not  easy, 
and  relatively  highly  trained  individuals 
must  be  available  to  encode  the  data  for 
later  use;  this  task  cannot  be  left  to 
unknowledgable  persons.  Worthwhile  also 
would  be  an  effort  to  review  existing  data 
and  data  gathering  efforts  related  to 
computer  security  such  as  data  banks 
maintained  by  Donn  Parker  at  SRI 
International;  Robert  Courtney  of  Robert 
Courtney,  Inc.,  and  Glenn  M.  Jones  of  the 
Pentagon  Joint  Data  Services  Support 
Center.  After  such  a  review,  significant 
gaps  would  be  identified  and  the  process  of 
gathering  new  needed  data  could  be  started. 
Such  work  will  require  knowledgable  persons 
to  encode  the  data.  An  initial  effort  at 
this  is  underway  at  the  National  Computer 
Security  Center,  under  the  direction  of  Roy 
Wood. 

2 . 6  Uncertainty 

Estimates  of  throat  likelihoods  are  hard  to 
elicit  and  validate;  nevertheless,  the  risk 
analysis  community  has  already  made  some 
important  progress  in  the  area  of 
uncertainty  by  using  probability 
distributions  to  quantify  uncertainty  about 
exposures  and  severity  of  effects,  In 
particular,  work  in  nuclear  safety  by 
Rasmussen  [NRC75],  and  in  the  more  general 
field  of  probabilistic  risk  assessment 
[Howa76,  MorgS4,  Henr85,  CoxSl]  is 
relevant.  However,  this  Bayesian, 
probabilistic  approach  is  only  a  start,  and 
there  remain  quite  a  few  unanswered 
questions  related  to  uncertainty.  There  is, 
for  example,  a  growing  literature  on  low 
probability,  high  loss  events. 
Nevertheless,  we  are  still  uncomfortable 
handling  these  in  the  real  world. 

A  number  of  important  questions  with  respect 
to  uncertainty  remain  unanswered  in  the 
specific  area  of  computer  security  [Henr86]: 

Should  all  risks  be  quantified?  Should 
all  uncertainties  about  numerically 
expressed  risks  be  quantified?  Are 
linguistic  expressions  of  severity  and 
uncertainty  ("rarely",  "likely") 
sufficient,  or  are  they  inevitably 
bedevilled  by  ambiguities?  If  not,  are 
probabilities  always  the  best  approach? 
What  of  fuzzy  sets,  Dempster-Shaf ter 
calculus,  and  various  other  approaches 
to  representing  uncertainty,  both 
quantitative  and  qualitative,  developed 
by  researchers  in  artificial 
intelligence  and  expert  systems?  One 
fuzzy  set  based  approach  [Schmucker]  has 
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already  been  applied  to  computer 
security.  Is  it  better  than  the  others? 


constantly  change,  as  the  life  cycle  of  the 
system  goes  on,  and  reflect  the  updated 
configuration  of  the  system. 


Studies  which  compare  these  approaches  (on 
both  theoretical  and  practical  criteria), 
assess  their  merits  and  drawbacks,  and  start 
to  develop  guidelines  about  which  may  be 
appropriate  under  what  conditions  are 
needed . 

2.7.  Desirability  of  a  general  risk  model  as 
a  conceptual  framework 

If  a  general  risk  model  could  be  developed 
which  could  be  used  by  both  the  risk 
analysis  and  computer  security  communities, 
it  would  provide  significant  benefits  to 
both  communities  in  the  areas  of  testing, 
methodology  evaluation,  and  completeness  of 
analysis.  Such  a  conceptual  framework 
should  be  very  flexible,  be  able  to  handle 
numerous  types  of  risk  analysis  computer 
security  problems,  and  be  able  to  handle  all 
external  policies  imposed  on  the  problem. 
It  should  be  able  to  be  easily  refined  as 
new  knowledge  (for  example,  from  the  test 
beds  and  pilot  studies  described  above) 
becomes  available  or  new  constraints  appear. 
It  should  be  acceptable  to  both  communities 
and  rich  enough  to  represent  just  about  all 
computer  security  situations.  Without  such 
a  model,  "we  will  continue  to  have  methods 
that  are  as  different  as  apples,  oranges  and 
pears  and  which  will  produce  results  which 
cannot  be  compared"  [Katz85], 

The  interrelationships  between  threats, 
threat  frequencies,  vulnerabilities, 
safeguards,  risk,  outcomes,  etc.,  should  all 
be  described  in  a  formal  way  so  that  a 
common  understanding  of  the  risk  analysis 
process  emerges  [KatzS5],  Such  a  model 
might,  at  least  in  part,  not  be  highly 
mathematical,  since  it  would  ideally  make 
effective  use  of  case-  based  and 
quasi-statistical  data  described  in  Section 
2.5.  It  should  be  able  to  handle  but  not  be 
limited  to  techniques  such  as  the  FIPS  PUB 
65  annual  los3  expectancy  method  [ NBS 79]; 
commercial  methodologies  such  as  return  on 
investment  method  [Coln85]  or  Bayesian 
decision  support  [0zie86];  and  perhaps  even 
a  qualitative  fuzzy  set  theoretical  approach 
[ Schm84 ] . 

The  model  would  provide  generic  threats, 
assets,  etc.  as  well  and  would  fit  a  number 
of  specific  methods  described  in  [Hoff86], 
it  must  also  allow  for  approximations  to 
those  functions  we  do  not  know  how  to 
define.  This  will  allow  us  to  implement 
tools,  in  the  near  terra,  that  represent 
simplifications  to  more  complex 
interrelationships.  As  we  obtain  more 
insight  about  interrelationships,  wo  should 
be  able  to  replace  the  simplistic 
representations  with  more  complex  ones. 
Furthermore,  it  must  allow  alternative 
methods  for  different  purposes;  it  should 
allow  appropriate  combination  of  qualitative 
and  quantitative  input  data;  and  it  should 
be  consistent  when  applied  to  the  same 
problem  by  two  different  teams  of  people 
using  the  same  data. 

Finally,  it  should  be  a  "living  model"  (in 
the  words  of  H.  0.  Lubbes)  which  is  able  to 


2.8.  Dearth  of  Metrics  for  Risks  and  for 
Risk  Analysis  Methodologies 

One  significant  lack  today  is  metrics  fcr 
risk  analysis  and  risk  management.  There  is 
no  currently  accepted  set  of  criteria 
against  which  all  methods  can  be  compared. 
It  is  difficult  evaluate  or  to  convey  the 
advantages  and  disadvantages  of  a  given 
methodology  or  tool  when  no  accepted 
evaluation  metric  exists.  Until  such  a  set 
of  criteria  is  developed,  we  can  expect 
proliferation  of  various  methodologies,  most 
of  which  are  adaptations  of  previous  ones 
(even  if  the  previous  ones  have  serious 
deficiencies ) . 

A  deeper  problem  is  the  lack  of  metrics  for 
risk,  even  within  the  risk  analysis 
community.  There  has  been  little  research 
on  value  tradeoffs  to  guide  policy  decisions 
(with  some  notable  exceptions  such  os  the 
roughly  $1  million  value  put  on  a  human  life 
in  airline  safety  risk  analysis,  and  $1,000 
cost  equivalence  of  a  man-rem  of  exposure 
used  in  nuclear  regulation).  In  computer 
security  such  metrics  (e.g.,  a  dollar  value 
put  on  a  breach  of  secret  defense 
information)  are  scarce.  One  such  is  an 
initial  attempt  at  a  multi-attribute  utility 
function  related  to  congressional  options  on 
a  number  of  issues  in  information  security 
[Brow85].  There  is  also  little  work  on 
generalization  of  binary  logic  to  multiple 
states  which  handle  reliability  with 
degraded  performance  (e.g.,  a  safeguard  that 
works  some  of  the  time  or  which  partially 
works . 

2.9.  Appropriateness  of  Automation 

Recently,  there  has  been  a  proliferation  of 
computer  security  risk  analysis  tools  and 
products  [Hoff85,  Fiks85,  Henr85]  which  are 
particularly  useful  in  getting  the  risk 
analysis  started,  allowing  quick  sensitivity 
analyses,  and  producing  reports.  Despite 
these  advantages,  the  risk  analysis 
community  has  been  quick  to  caution  against 
premature  development  or  use  of 
quantification,  automation,  or  expert 
systems.  They  are  concerned  that  "Issues  of 
modeling,  uncertainty  assessment  and 
judgment  of  value  require  the  kinds  of 
thinking  that  software  tools  can't  provide 
right  now"  and  should  only  be  used  for 
routine  calculations,  such  as  implementing 
the  logic  cf  fault  trees. 

In  the  workshop  which  led  to  this  paper,  all 
agreed  that  there  should  not  be  a  rush  to 
computerize  and  that  automated  tools  should 
not  claim  or  imply  more  than  is  there;  in 
essence,  automated  tools  are  fine  as  a 
means,  not  as  an  end.  Some  subtle  dangers 
are  involved  here  also,  including  the  lack 
of  credibility  when  the  systems  don't 
deliver  what  they  promise  and  the  locking  in 
of  inappropriate  methodologies  by  premature 
computerization  and  inflexible  software. 

No  one  was  willing  to  advocate  the  idea  of 
using  expert  systems  or  artificial 
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intelligence  in  risk  analysis  today .  at  the 
early  stage  o £  development  these  fields  are 
in.  However,  if  a  suitable  general  model 
can  he  built,  then  prior  experience  in  the 
codification  and  treatment  of  expert 
opinion  might  be  used  in  the  development  of 
an  expert  system  to  produce  a  risk 
management  tool  which  would  be  quite 
useful.  This  would  be  a  lot  more  than  an 
electronic  checklist:  it  would,  based  upon 
information  related  to  the  specific 
installation  being  analyzed,  suggest  actions 
to  take  to  improve  security.  Such  systems 
have  been  built  or  proposed  in  many  areas, 
including  medicine  and  business  planning. 
Naturally,  all  the  rules  used  by  such  a 
system  would  have  to  be  traceable  and  clear, 
at.d  the  system  would  have  to  handle 
nontechnical  as  well  as  technical  risk  to 
computer  systems. 
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An  essentially  new  methodological  area  of 
risk  analysis  is  proposed,  in  which  the  risks 
are  multiple  and  diffuse  und  the  source  of 
risk  is  a  human  adversary.  Computer  security 
is  a  special  case  of  particular  interest. 

The  methodological  needs  for  both  risk 
assessment  and  risk  management,  dealing  with 
these  types  of  risk,  are  defined  and  related 
to  the  current  state-of-the-art  in  other 
branches  of  risk  analysis  and  decision 
analysis.  Distinctive  analytic  techniques 
are  suggested,  extending  the  existing  armory 
of  analytic  tools  for  ri-ik  analysis.  Issues 
and  approaches  include:  formulation  of  risk 
consequences  (e.g.,  macro  models  and  plural 
analysis) ;  evaluating  risk  consequences 
(e.g.,  via  multiattribute  utility  functions 
and  alternative  devices) ;  predicting  adver¬ 
sarial  behavior  (game  theory  and  decision 
analytic  models) ;  predicting  complex  risk  af¬ 
termaths  (step-through  simulation) ;  determin¬ 
ing  institutional  and  social  value;  specify¬ 
ing  the  impact  of  action  options;  and  choice 
and  implementation  of  options. 

1.  INTRODUCTION 

1.1  Evolution  of  Risk  Analysis  Methodology 

Risk  analysis,  as  a  distinct  field  of  in¬ 
quiry,  has  been  steadily  evolving  in  terms  of 
the  complexity  of  risks  it  addresses,  and 
thus  requires  increasingly  ambitious  analytic 
tools.  Risk  situations  might  be  charac¬ 
terized  along  two  dimensions:  the  source  of 
the  risk  and  the  effect  of  the  risk.  The 
source  might  be  represented  along  a  continuum 
between  non-adversarial  and  a  malevolent  ad¬ 
versary.  The  effect  of  the  risk  might  range 
along  a  continuum  between  focused  (or  exact) 
and  diffuse  (or  inexact) .  These  dimensions 
of  risk  analysis  are  shown  conceptually  in 
Figure  1. 

i-i-i  Slimle. . fg.gused  risk.  ,npn-adver,garial 

source.  Historically,  risk  analysis  research 
first  addressed  the  simplest  type  of  risk: 
focused  risk  whose  source  is  nature — i.e., 
non-adversarial.  This  risk  is  typified  by 
the  risk  faced  by  insurance  companies.  Risk 
is  focused  in  that  it  can  be  expressed  along 
a  single,  easily  measured  dimension,  such  as 
money;  and  the  bearer  of  the  risk  is  a  single 
entity,  such  as  a  corporation,  a  joint  ven¬ 
ture,  or  an  individual.  In  some  of  these 
cases,  such  as  life  and  health  insurance, 
risk  assessment  is  simplified  by  the 
availability  of  substantial  historical 
records,  which  permit  uncontroversial  deter¬ 
mination  of  probabilities.  In  other  cases, 
human  judgment  must  play  a  significant  role 
in  th8  assessment,  typified  by  a  recent  case 
where  Lloyd's  of  London  insured  against  the 
discovery  of  the  Loch  Ness  Monster  (for  a 
manufacturer  of  scotch  who  had  offered  a  mil¬ 


lion  pound  reward  to  the  happy  discoverer) . 
However,  this  still  remains  the  simplest  case 
of  risk  analysis. 

1.1.2  Multiple  focused  risk.,  non-adversarial 
source.  Within  the  last  ten  years,  risk 
analysis  research  has  expanded  to  consider 
more  complex  risks,  ones  that  are  somewhat 
more  diffuse  than  the  simple  risks  that  are 
addressed  by  insurance  companies.  This  risk 
is  typified  by  health  or  safety  risks  of  the 
type  addressed  by  many  governmental  regula¬ 
tions  (see  Figure  1) .  It  is  somewhat  more 
diffuse  than  the  first  case,  because  the  ob¬ 
jects  at  risk  are  multiple  and  the  risks 
themselves  are  multiple,  even  though  the 
risks  are  defined  along  easily  measured 
dimensions  (such  as  death  and  health  effects) 
and  the  objects  at  risk  are  easily  specified 
(such  as  human  populations) .  The  source  of 
this  risk,  however,  is  non-adversarial,  and 
is  often  the  combination  of  nature  and  tech¬ 
nology  (such  as  drugs  or  nuclear  power 
plants) .  As  with  life  insurance,  quantifica¬ 
tion  of  the  risks  oan  typically  be  anchored 
to  observed  frequencies,  but  human  judgment 
has  a  significant  role  to  play  (for  example, 
in  predicting  events  that  have  never  oc¬ 
curred,  such  as  a  reactor  core  meltdown) . 

This  health  and  safety  area  has  now  achieved 
some  considerable  measure  of  technical 
maturity  in  predicting,  evaluating  and  manag¬ 
ing  the  risks  involved,  with  significant  sup¬ 
port,  for  example,  from  the  Risk  Analysis 
Program  at  NSF.  It  uses,  among  other  tech¬ 
niques,  personalized  (Bayesian)  probability 
for  quantifying  risks,  and  multiattribute 
utility  theory  (MAUT)  for  trading  of  death 
against  disability  against  economic  cost. 

The  literature  in  this  area  is  now  quite  ex¬ 
tensive,  and  the  state-of-the-art  is 
reasonably  represented  in  the  following 

selected  references:  Covello  &  Menkes1; 
Keeney  &  Raiffa2;  Lave3;  Ricci,  et  al.4; 
Rowe5;  Risk  Analysis6;  Schwing  &  Albers7. 

1-1-3  Diffuse  risk,  non-adversarial  source. 

A  risk  which  is  substantially  more  diffuse, 
but  still  non-adversarial  (i.e.  technologi¬ 
cal)  is  typified  by  environmental  risk 
analysis,  whero  multiple  ill-defined  effects 
are  experienced  by  often  equally  ill-defined 
objects  at  risk  (see  Figure  1).  Environmen¬ 
tal  risk  analysis  has  been  spurred  during  the 
past  decade  or  so  by  the  National  Environmen¬ 
tal  Protection  Act  (NEPA) ,  the  establishment 
of  the  Environmental  Protection  Agency,  and 
the  resulting  requirement  for  environmental 
assessments  and  environmental  impact  state 

ments  for  a  wide  range  of  projects  (Leaps8) . 
Like  most  health  and  safety  risk  analysis,  it 
is  largely  motivated  by  government  regula¬ 
tion. 
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1.2  New  Risk  Analysis  Requirements 

New  categories  of  risk  are  now  emerging, 
which  require  a  new  analytic  technology, 
which  can  accommodate  risk  analyses  in  the 
whole  plane  of  Figure  1.  That  is,  where  the 
objects  at  risk  and  the  nature  of  the  risk 
could  be  diffuse,  and  in  where  the  source  of 
risk  could  be  a  malevolent  adversary.  Such 
risks  might  be  termed  "diffusa  risks  from  ad¬ 
versarial  sources"  (DR/ AS) .  Most  types  of 
computer  security  are  prime  examples  of  this 
type  of  risk,  to  be  discussed  below.  Other 
examples  include  theft  and  sabotage  at 
nuclear  and  other  energy  facilities, 
espionage  and  terrorism  in  its  many  forms. 
These  risks  might  be  characterized  as  the 
points  in  the  top  right  comer  of  Figure  1. 
Multiple  effects  are  not  necessarily  diffuse. 
One  of  the  multiple  effects  of  environmental 
risk  might  be  the  destruction  of  a  wildlife 
sanctuary,  which  is  quite  focused,  compared 
with  the  breached  security  effect  of  a  com¬ 
puter  system,  which  can  only  be  evaluated 
with  consideration  of  a  possibly  complex  pat¬ 
tern  of  "aftermaths"  leading,  for  example,  to 
possibly  harmful  uses  of  information  by 
potential  enemies  of  the  United  States. 

The  existing  analytic  methodology  is  not  wall 
adapted  to  the  new  levels  of  complexity  in¬ 
troduced  by  this  class  of  risk.  There  have 
been  isolated  instances  of  promising 
methodological  innovation,  developed  in  the 
process  of  solving  specific  practical 
problems,  for  example,  consequence  evaluation 
for  nuclear  safeguards.  However,  little  has 
been  done  tc  unify  or  generalize  them.  Sys¬ 
tematic  approaches  have  also  been  developed 
on  analogous  problems  (for  example,  modeling 
adversaries  in  negotiation  and  competitive 
situations,  and  modeling  complex  future 
scenarios  in  military  planning) .  However, 
they  have  not  been  adapted  for,  or  applied 
to,  the  problem  of  analyzing  and  managing 
risk. 

Although  nearly  all  of  recent  risk  analysis 
literature  has  been  on  physiological  risks 
from  technological  sources  plus  a  little  on 
environmental  risks  and  on  natural  hazard 
sources  (as  typified  by  the  coverage  of  the 
journal  Risk  Analysis^ ,  DR/AS  risk’analysis 
has  not  been  entirely  lacking.  It  has,  how¬ 
ever,  been  piecemeal  and  typically  case- 
specific.  At  Decision  Science  Consortium, 
Inc.  (DSC) ,  for  example,  wo  have  performed 
risk  analyses  for  nuclear  safeguards  against 
theft,  malevolent  acts  against  energy 
facilities,  and  international  monitoring  of 
nuclear  proliferation,  and  methodological 
innovations  have  been  developed  and  applied. 
However,  such  developments  have  not  been  syt. 
tematized  or  codified  for  general  use. 

Analytic  techniques  for  modeling  diffuse  fu¬ 
ture  effects  are  baing  developed  through  ap¬ 
plication  areas  other  than  risk  analysis, 
notably  defense  planning,  which  needs  to  take 
into  account  the  unfolding  of  complex 
military  scenarios.  Various  forms  of 
scenario  specification  and  simulation  have 
been  devised  including  step-through  simula¬ 
tion  (Ulvila,  Brown,  &  Randall9;  Ulvila,  & 

Brown10) ,  which  economizes  on  mental  burden. 
These  methods  are,  on  the  whole,  at  an  early 


stage  of  development  and  have  not  been 
adapted  to  problems  of  DR/ AS. 

A  distinctive  aspect  of  "adversarial  source" 
of  risk  is  the  role  of  motivation  and  percep¬ 
tion,  which  interacts  in  complex  ways  with 
risk  management  efforts.  For  example,  where 
there  are  several  alternative  ways  for  real¬ 
izing  a  hazard,  (e.g.,  breaches  of  informa¬ 
tion  security  in  a  computer  system,  or  ways 
for  a  proliferator  to  divert  nuclear 
material),  a  risk  manager's  success  in  block¬ 
ing  one  path,  if  perceived  by  the  adversary, 
may  lead  the  latter  to  reassign  his  effort  in 
other  directions.  Again,  analytic  approaches 
to  this  class  of  problem  have  been  attempted 
in  non-risk  fields,  notably  game  theory  (Luce 

&  Raiffa11;  Shubik12) ,  and  the  use  of 
prescriptive  decision  analysis  models  to  pre 
diet  adversarial  and  other  human  behavior. 

For  example,  Brown  et  al.12  uses  prescriptive 
decision  analysis  models  to  predict  NATO 
response  to  an  impending  Warsaw  Pact  attack. 

Interactive  decision  theory,  which  incor¬ 
porates  concepts  from  both  decision  analysis 
and  game  theory,  has  been  developed  for  nego¬ 
tiation  applications,  and  also  has  suggestive 
analogies  with  the  case  of  DR/AS  risk 

analysis  (Raiffa14;  ulvila15). 

1>3  Computer  Security  as  a  Special  Case 

Most  computer  security  risks  are  special 
cases  of  this  new  area,  but  some  types  (e.g., 
computer  theft)  have  foaused  effects  (money) , 
and  others  have  non-advorsarial  sources 
(e.g.,  computer  reliability). 

The  tools  currently  available  for  risk 
analysis  within  the  computer  security  com¬ 
munity  draw  very  little  on  previous  risk 
analysis  work,  partly  because  the  computer 
security  community  is  generally  unaware  of 
this  work  and  partly  because  computer 
security  problems,  being  largely  DR/ AS,  have 
not  always  been  readily  amenable  to  many  of 
the  traditional  risk  analysis  techniques. 

The  computer  security  community  has,  in  the 
main,  been  using  ill-fitting  adaptations  of 
risk  analysis  methods  that  were  developed  for 
significantly  different  problems.  One  of 
these  is  the  Annual  Loss  Expectancy  (ALE) 
method  (FIPS  PUB  65)  based  on  practices  in 
the  insurance  business,  where  the  risk  of 
concern  is  that  of  losing  money  in  insurance 
claims.  Usually  these  methods  are  not  ap¬ 
propriate  in  situations  where  the  cause  of 
the  risk  is  a  human  adversary  and  where  the 
effects  of  the  threat  are  diffuse.  With  com 
puter  security,  there  may  be  a  human  adver¬ 
sary,  such  as  a  "hacker"  (Levy16)  and  the  ef¬ 
fects  of  the  threat  are  diffuse  because  once 
data  is  compromised,  it  may  be  impossible  to 
precisely  specify  the  effects. 

In  computer  security,  multiple  risks  must  be 
considered,  and  these  risks  are  not  always 
easily  quantified  (as  contrasted  with  money, 
injuries,  or  deaths) .  The  threats  will  vary 
from  one  installation  to  another.  The  coun¬ 
termeasures  available  to  handle^tha  threats 
include  not  only  technical  measures,  but  also 
physical  and  administrative  security  tech- 
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niques.  As  in  many  other  areas,  there  are 
very  little  case  data  available. 

2.  RESEARCH  NEEDED 

Specific  analytic  techniques  need  to  be 
developed  to  address  the  distinctive  features 
of  risks  which  are  multiple  and  diffuse  and 
the  source  of  risk  may  be  a  malevolent  adver¬ 
sary.  Computer  security  would  be  an  excel¬ 
lent  special  case  to  exercise  them  on. 

Developing  an  appropriate  methodology  for 
DR/ AS  problems  can  build  on  past  work,  such 
as  the  state-of-the-art  of  risk  analysis  as 
used  in  conventional  application  areas  (Risk 

Analysis6) ,  case  studies,  completed  and  ongo 
ing,  of  specific  attempts  to  analyze  computer 

security  and  other  DR/AS  problems  (Brown17) ; 
a  review  of  decision  science  methodology  for 
problems  analogous  to  DR/AS  (Brown,  et 

al.13);  and  initial  efforts  to  develop  a 
methodological  paradigm  for  the  new  dimen¬ 
sions  (Brown  &  Lindley18 ;  Ulvila  &  Brown10; 
Brown  &  Feuerwerger19) . 

In  keeping  with  standard  risk  analysis  prac¬ 
tice,  wo  distinguish  two  analytic  tasks: 
risk  assessment  and  risk  management.  Risk 
assessment  involves  quantifying  the  probabil-' 
ity  of  unfavorable  outcomes  in  the  absence  of 
any  deliberate  intervention.  Risk  management 
involves  the  evaluation  of  potential  measures 
to  manage  the  risk,  i.e. ,  to  reduce  it  or  its 
consequences.  Both  phases  involve  identify¬ 
ing  potential  relevant  consequences,  their  • 
probabilities  of  occurrence,  and  their  eval¬ 
uation  if  they  do  occur. 

An  appropriate  unifying  methodological 
perspective  is  that  of  personalized  decision 
analysis,  which  incorporates  human  judgment 
in  quantifying  uncertainty  and  value  in  the 

process  of  prescribing  action  (Raiffa20; 

Brown,  et  al.21).  A  schematic  outline  of  one 
such  .analysis  is  given  in  Figure  2. 

For  this  new  type  of  DR/AS  problem,  we  sug¬ 
gest  that  its  methodological  needs  for  both 
risk  assessment  and  risk  management  need  to 
be  defined  and  related  to  the  current  sttta- 
of-the-art  in  other  branches  of  risk  analysis 
and  decision  analysis,  within  this  new  area, 
we  propose  a  research  plan  for  developing 
methodologies  where  the  needs  are  greatest 
and  with  special  application  to  of  computer 
security.  The  methodology  can  bs  exercised 
on  live  cases,  primarily  in  the  rocess  of 
conducting  a  complete  risk  analysis  for  an 
unclassified  version  of  a  live  problem  of 
computer  security  at  a  large  defenre 
facility.  We  now  describe  this  plan  more 
fully. 

3 .  DELINEATING  THE  NEW  TYPE  OF  RISK  ANALYSIS 

ibb/mi 

To  set  the  stage  for  a  broader  program  of 
methodological  and  data  gathering  research  we 
argue  that  DR/AS  is  a  class  of  risks 
(typified  by  large  areas  of  computer 
security,  nuclear  safeguards,  espionage  and 
terrorism)  that  is  distinguished  from  the 


more  conventional  areas  of  risk  analysis  in 
similar  ways,  such  that  they  could  be  use¬ 
fully  studied  together,  leading  to  the 
development  of  a  unified  methodology.  The 
dominant  distinguishing  features  shared  by 
this  class  of  problem  refer  to  the  nature  of 
the  risks  and  their  sources  as  .they  bear  on 
methods  for  assessing  them  and  evaluating 
their  seriousness. 

The  features  are  the  diffuseness  of  the  risks 
(including  multiple  dimensions,  multiple  and 
ill -defined  risks,  and  uncertain  consequences 
extending  over  time) ;  and  the  fact  that  the 
major  sourca  of  risk  is  a  human  adversary 
(whose  behavior  is  not  susceptible  to  the 
same  prediction  methods  as  inanimate  or  at 
least  nonmalevolant  sources) .  There  may  be 
other  dimensions  of  analogy  or  disanalogy  to 
be  explored. 

As  shown  in  Figure  l,  not  all  risk  analysis 
problem  areas  fall  cleanly  in  or  out  of  the 
DR/ AS  category.  For  example,  theft  of 
proprietary  data  stored  in  a  computer  system 
("Computer  theft"  in  Figure  1) ,  as  a  sub¬ 
category  of  computer  security,  has  the  ele¬ 
ment  of  an  adversarial  source  (e.g.,  the 
thief) ,  but  the  risk  itself  may  be  monetary 
(and  to  this  extent  has  much  in  common  with 
the  financial  risk  facing  insurance 
companies')  .  Conversely,  there  are  areae 
where  the!  risk  is  diffuse  (such  as  certain 
kinds  of  environmental  impact),  but  the 
source  is  inanimate  and  technological  and  in 
this  respect  similar  to  health  an'd  safety 
risk  analysis  (see  Figure  1). 

Special  attention  needs  to  be  paid  to  the 
distinctive  methodological  needs  of  computer 
security  as  a  legitimate  area  of  risk 
analysis  research  in  its  own  right.  A  DOD- 
spontored  workshop  on  computer  security  risk 
analysis,  chaired  by  Lance  Hoffman  of  George 

Washington  University22,  was  recently  held. 

It  was  suggested  there  that  a  general  concep¬ 
tual  model  for  computer  security  can  be 
developed  and  used  to  modal  unauthorized  dis¬ 
closure,  destruction,  modification  of  data 
and  denials  of  service  from  the  point  of  view 
of  risk  analysis.  The  problem  of  setting  a 
value  on  intangibles  deserves  to  be  examined, 
as  well  as  problems  involved  in  charaoteriz 

ing  and  propagating  uncertainties  (Brown23) 
which  are  to  date  almost  unrecognized  by  the 
computer  security  community.  Also  of  inter¬ 
est  are  problems  in  communicating  computer 
security  risks  to  various  risk  management  ac¬ 
tors  (e.g. ,  Congress  and  facility  managers) 
and  constituency  groups  (e.g.,  segments  of 
the  general  public,  system  manufacturers  and 
vendors,  end-users,  government 
administrators) . 

i.  DEVELOPING  SELECTED  METHODOLOGIES 
FOR  DR/AS  PROBLEMS 

Specific  pieces  of  new  methodology  need  to  be 
developed  to  address  the  most  serious 
deficiencies  in  the  current  state-of-the-art 
applied  to  DR/AS  risk  analysis  problems,  in 
the  light  of  the  results  of  the  effort 
described  in  Section  3.  They  can  be  il¬ 
lustrated  in  the  context  of  computer  security 
and  other  DR/AS  examples,  and  address  both  of 
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the  standard  divisions  of  risk  analysis! 
risk  assessment  and  risk  management. 

4.1  Risk  Formulation 

We  are  concerned  with  risky  situations  where 
the  possible  consequences  are  diffuse,  i.e., 
they  cannot  readily  be  characterized  by  a  few 
simply  specified  standard  events  or  measures, 
such  as  monetary  costs,  a  core-melt  accident, 
or  a  number  of  deaths.  The  question:  "What 
is  risk?"  cannot  be  simply  formulated  in 
operational  terms  and,  indeed,  the  appropri¬ 
ate  formulation  may  vary  with  the  situation 
and  defy  standardized  definition. 

Alternative  methods  and  principles  for  for¬ 
mulating  risk  deserve  investigation.  At  this 
time,  it  appears  that  four  possibilities  show 
a  high  degree  of  promise.  First,  risk  might 
be  specified  in  a  "macro  model"  containing 
few  high-level,  abstract  attributes  that 
could  be  expected  to  span  the  range  of  con¬ 
cerns  in  given  risk  assessment.  For  example, 
computer  security  risk  might  be  specified 
along  such  attributes  as  national  security, 
economics,  privacy,  cost,  civil  liberties, 
and  others.  As  another  example,  a  macro 
model  of  the  risk  of  nuclear  material  theft 
(shown  in  Figure  3)  might  specify  risk  along 
the  attributes  of  material  stolen,  deaths, 
damage,  possession  of  material  by  adversary 
at  any  time,  apprehension  of  adversary, 
penetration  of  safeguard  system. 

•Second,  the  macro  model  might  be  extended  to 
represent  the  risk  from  the  points  of  view  of 
several  different  constituencies.  For  ex¬ 
ample,  the  risk  at  a  U.S.  government  computer 
facility  might  be  represented  from  the  point 
of  view  of  the  facility  manager,  the  U.S. 
legislature,  and  several  segments  of  the 
public.  As  another  example,  the  risk  of 
nuclear  material  theft  might  be  represented 
from  the  points  of  view  of  facility  manager, 
government  regulator,  and  society,  as  il¬ 
lustrated  schematically  in  Figure  2 . 

Third,  since  macro  models  may  be  too  highly 
aggregated  and  broad  to  represent  all  impor¬ 
tant  details  of  the  risk,  a  series  of 
"feeder"  models  may  be  developed  and  incor¬ 
porated  into  the  modeling  process  to  provide 
detailed  analyses  of  the  moat  important 
aspects  of  risk.  For  example,  a  macro  model 
of  nuclear  power  plant  risk  might  use  a 
feeder  probabilistic  risk  assessment  (PRA)  to 
provide  a  detailed  analysis  of  the  magnitude 
of  accidental  exposure  to  radiation. 

Fourth,  since  no  single  specification  of  a 
diffuse  risk  is  always  adequate  for  all  pur 
poses,  techniques  of  "plural  analysis"  (Brown 

and  Lindl'ey18)  should  be  investigated. 

Plural  analysis  involves  pursuing  two  or  more 
separate  approaches  to  the  same  problem  and 
then  formally  reconciling  or  pooling  the  dif¬ 
ferent  results. 

4.2  Consequence  Evaluation 

In  addition  to  problems  of  formulating  risks, 
situations  with  diffuse  risks  pose  problems 
in  evaluating  the  consequences  of  the  risk. 
The  problem  is  due  primarily  to  the  need  to 
characterize  multiple  attributes  of  risk. 


Thus,  not  only  do  the  individual  attributes 
need  to  be  assessed,  but  comparisons  across 
different  categories  of  risk  must  be  deter¬ 
mined.  For  example,  in  computer  security 
risk,  total  risk  might  be  characterized  in 
terms  of  national  security,  economics, 
privacy,  cost,  and  civil  liberties,  and 
others.  As  assessment  of  total  risk  requires 
a  method  to  compare  a  level  of  risk  on  one 
attribute  with  the  level  of  risk  on  another 
attribute.  Multiattribute  utility  analysis 

(Keeney  and  Half fa2)  offers  a  promising 
method  for  development  such  comparisons. 

It  is  worth  exploring  general  ways,  both  of 
defining  appropriate  s-ales  for  multiat- 
tribute  utility  analysis,  and  of  deriving 
value  parameters  that  compare  different  at¬ 
tributes.  The  methods  can  be  exercised  in 
the  context  of  computer  security.  A  tanta 

tive  example  is  presented  in  Brown17,  which 
evaluates  alternative  national  computer 
security  policies.  One  might  also  build  on 
other  relar.ed  work  which  involved  developing 
an  index  of  hazard  for  radioactive  waste, 

which  is  reported  in  Watson24.  This  involved 
field  work  to  elicit  value  judgments  from 
three  sources:  members  of  the  general 
public,  the  responsible  Government  ad¬ 
ministrator,  and  technical  experts.  The 
analysis  can  be  either  weakly  or  strongly 
quantified  (see  Figures  5  &  6,  respectively) . 

4.3  Modeling  the  Aftermath  of  a  Risk  Event 

An  alternative  method  to  macro  models  for 
handling  diffuse  risk  is  Monte  carlo  simula¬ 
tion,  where  complex  possible  consequences  of 
aftermaths  to  a  risk  are  represented  as  a 
sampling  of  possible  complete  paths.  How¬ 
ever,  for  diffuse  risks,  the  conventional 
Monte  Carlo  simulation  requires  specifying 
probabilities  for  all  possible  contingencies 
and  poses  an  unmanageably  heavy  burden.  We 
have  developed  an  alternative,  called  "step- 
through  simulation,"  in  the  context  of  dif¬ 
fuse  consequences  of  military  actions,  where 
an  expert  and  a  model  interact  in  producing 

each  trial  (Ulvlla,  Brown,  and  Randall9;  Ul- 
vila  &  Brown10) . 

4.4  Madeline  Adversarial, .Bshaylpr 

The  methodological  significance  of  the 
"adversarial  source"  of  risks  is  that  an¬ 
ticipation  of  deliberate,  hostile  human  ac¬ 
tion  requires  special  assessment  techniques, 
which  are  not  appropriate  for  inanimate,  or 
at  least  nonadversarial ,  sources  of  risks 
(c.f.  human  error  in  the  operation  of  nuclear 
plant) .  A  major  avenue  to  be  explored  is 
modeling  the  decision  processes  of  the  adver¬ 
sary. 

Game  theory  (Luce  and  Raiffa11;  Shubik12)  is 
one  implementation  of  this  idea,  though  the 
need  for  restrictive  assumptions  on  the 
rationality  of  behavior  and  extensive  infor¬ 
mation  available  to  the  adversary  severely 
limit  the  practicality  of  this  approach. 

A  more  promising  alternative  is  to  anchor 
prediction  of  an  adversary's  behavior  to  that 
which  a  decision-analytic  model  of  his  choice 


would  indicare.  This  has  been  used  in  a 
study  concerned  with  probabilistically  pro 
dieting  a  NATO  response  to  an  impending  War 

saw  Pact  attack  (Brown  et  al . 13 ) .  The 
literature  for  predicting  deliberate,  but 
nonadversarial ,  human  action  can  also  be 
reviewed  for  applicability. 

A  key  element  in  this  prescriptive  approach 
to  prediction,  which  needs  substantial 
development,  is  handling  the  slippage  between 
prescription  and  prediction,  acknowledging 
the  fact  that  the  adversary  may  not  behave  as 
the  decision  analysis  of  his  choice  would  in 
dicate.  The  psychological  work  of  Duncan 

Luce25  and  the  interactive  decision  analysis 

work  of  Howard  Raiffa14  provides  a  starting 
point.  There  has  also  been  some  more 
specific  work  on  this  problem,  in  the  context 
of  predicting  nuclear  theft  behavior  of 
malevolent  acts  against  energy  facilities 

(Hill26) . 


The  object  this  paper  has  been  only  to  gat 
out,  for  comment  and  suggestion,  some 
preliminary  ideas  on  what  might  constitute  a 
fruitful  new  area  of  risk  analysis.  We 
believe  it  will  call  for  distinctive — and 
major — research  and  methodology  development, 
on  a  scale  comparable  to  that  which  has  been 
devoted  in  recent  years  to  health  and  eafety 
risk  analysis. 
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Abstract 


The  intent  of  this  paper  is  to  briefly 
inform  the  reader  of  the  controversy  brought 
about  by  National  Security  Decision 
Directive  145.  Also,  it  will  present  to  the 
reader  an  informative  report  of  the 
Assessment  and  Advice  (A&A)  effort  being 
carried  out  by  the  Applications  Systems 
Evaluations  Office  of  the  National  Computer 
Security  Center  (NCSC) .  The  opinion  of  the 
author  is  that  the  A&A  effort  is  one  of  the 
best  ways  for  the  NCSC  to  address  both  the 
directive  and  the  controversy.  The  paper 
wills 

1}  give  a  brief  account  of  NSDD  145  and 
the  Center. 

2)  describe  the  actual  process  of  an 
A&A  - 

-  for  federal  agencies  which  may 
wish  to  have  an  A&A  performed. 

-  for  training  computer  security 
evaluators  who  are  assigned  to 
an  A&A  team. 

3)  encourage  management  to  continue  the 
A&A  effort  - 

-  for  the  benefits  to  the  NCSC, 

-  for  the  benefits  to  the  federal 
government. 


Introduction 

There  is  nothing  more 
difficult  to  plan,  more  doubtful 
of  success,  nor  more  dangerous  to 
manage  than  the  creation  of  a  new 
system.  For  the  initiator  has  the 
enmity  of  all  who  would  profit  by 
the  preservation  of  the  old  system 
and  merely  lukewarm  defenders  in 
those  who  would  gain  by  the  new 
one.  1 

Niccolo  Machiavelli  is  credited  with 
making  this  enlightened  observation  in  the 
early  1500's,  but  his  accurate  account  of 
resistance  to  change  is  still  very  evident 
today.  A  Presidential  Directive  concerning 
the  issue  of  information  security  in  the 
federal  government  has  stirred  up  resistance 
on  many  fronts. 

NSDD  145 

“With  the  federal  government's  need  for 
computer  security  so  acute  and  so  obvious, 
it's  a  shame  that  the  White  House's  effort 
to  address  the  issue  has  become  so  mired  in 
controversy."2  This  quote  from  an  editorial 


1  Niccolo  Machiavelli,  The  Prince. 

2"Secur ity, “  Government  Computer  News. 

Editorial,  27  September  1985,  p.  14. 


in  the  weekly  Government  Computer  News 
(GCN)  expresses  the  contention  brought 
about  by  National  Security  Directive  (NSDD)' 
145  which  was  issued  by  the  National 
Security  Council  on  September  17,  1984,  and 
signed  by  President  Ronald  Reagan.  The 
directive,  which  is  titled  the  "National 
Policy  on  Telecommunications  and  Automated 
Information  Systems  Security,"  states  these 
policy  objectives:  1)  to  assure  the 
security  of  telecommunication  and  automated 
information  systems  that  process  and 
communicate  classified  and  other  sensitive 
national  security  information,  and  2)  to 
offer  assistance  in  the  protection  of 
certain  private  sector  information.  The 
National  Security  Agency  has  been  named  as 
the  leading  authority  for  accomplishing 
these  objectives.3 

Opposition  to  this  directive  has  many 
concerns,  ranging  from  the  American  Civil 
Liberties  Union's  concern  for  freedom  of 
information,  through  a  government  agency's 
security  specialist  who  says,  "We  don't 
want  someone  else  telling  us  what  to  do, "4 
to  some  in  Congress  who  are  upset  that  the 
policy  was  made  through  a  directive 
designed  by  the  National  Security  Council 
and  Bigned  by  the  President  without  public 
input  rather  than  by  legislation  which 
would  receive  public  hearings  and  a  full 
debate  in  Congress.  Mostly,  criticism 
stems  from  the  leadership  position  for 
information  security  given  to  the  National 
Security  Agenay.5  The  GCN  editorial 
concludes: 

Given  the  need  for  federal 
computer  security,  we  hope  the 
agency  is  up  to  the  task. 

Failure  could  set  back  the  whole 
process  by  several  years  and  many 
federal  agencies  are  already 
years  behind  in  security 
measures.6 

Actually,  many  government  standards 
concerning  computer  security  were  available 
prior  to  NSDD  145,  However,  these  policies 
are  often  ambiguous,  outdated,  or  cite 


3U.S.,  National  Security  Council, 
"National  Policy  on  Telecommunications  and 
Automated  Information  Systems  Security," 
National  Security  Decision  Directive  145 
(17  September  1984) . 

^Eric  Fredell,  "Agencies  Balk  at 
Control  Given  NSA, "  Government  Computer 
News,  27  September  1985,  p.  19. 

5Eric  Fredell,  "Security  Directive 
Lambasted, *  Government  Computer  News.  19 
July  1985,  p.  1. 

6"Security,"  GCN  editorial. 
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conflicting  information  and  their 
ineffectiveness  is  evident  by  the  lack  of 
security  in  the  computer  systems  of  the 
federal  government. 

The  Office  of  Management  and  Budget's 
(OMB)  Circular  A-71  requires  that  computer 
systems  with  sensitive  applications  be 
certified  and  accredited.  The  National 
Bureau  of  Standards'  (NHS)  Federal 
Information  Processing  Standards  Publication 
(FIPS  PUB)  102  details  procedures  for 
certification  and  accreditation  for  federal 
agencies  and  lists  more  than  eighty  federal 
computer  security  policies  and  guidelines. 
Numerous  Department  of  Defense  (DoD) 
regulations  also  exist  outlining  security 
requirements,  safeguards  for  classified 
information,  and  modes  of  operation.  Susan 
Menke  reports  the  ineffectiveness  of  these 
requirements  in  an  article  in  Federal  Times: 


In  the  past,  OMB  and  GAO  have 
tried  with  mixed  success  to  force 
everyone  to  think  hard  about  the 
risks  and  consequences  (of 
computer  and  computer  information 
loss) ... .Many  agencies  remain 
overwhelmed  by  conflicting, 
overlapping  security  directives 
and  so  far  haven't  made  much 
progress. .. .Others  hold  a  cynical 
laissez-faire  view... that  they'll 
roll  with  the  punches  when 
something  valuable  gets  stolen. 7 

NSDD  145  points  out  that  the  nation's 
security  is  in  jeopardy  if  the 
telecommunication  and  automated  information 
systems  which  process  national  security- 
related  information  continue  to  operate  aB 
they  have  in  the  past.  "The  technology  to 
exploit  these  electronic  systems  is 
widespread  and  is  used  extensively  by 
foreign  nations  and  can  be  employed  as  well, 
by  terrorist  groups  and  criminal  elements. *° 
With  all  the  policy  and  regulations 
concerning  information  security  that  have 
been  available,  no  one  agency  has  had  the 
responsibility  to  foster  computer  security. 
NSDD  145  has  directed  that  NSA  be 
responsible  for  aiding  agencies  that  process 
national  security  information,  and  now  that 
NSA  has  been  given  this  responsibility,  the 
controversy  spreads. 


To  make  NSDD  145  work  and  ease  the 
apprehensions  of  the  great  opposition,  the 
National  Security  Agency  has  plenty  to  do. 
The  ability  to  influence  others  toward 
greater  information  security  must  be  used 
with  aboveboard  procedures.  The  biggest  of 
the  concerns,  that  in  some  cases  borders  on 
paranoia,  is  of  MSA's  being  the  Orwellian 


7Susan  M.  Menke,  "Security  is  More  a 
Human  Issue  Than  a  Technical  One,"  Federal 
Times.  4  November  1965,  p.  18. 

8NSCD  145. 


"Big  Brother."  The  GCN  editorial, 
"Security,"  further  explains  the  "fear  of 
Big  Brother"  and  suggests  how  the  fear 
might  be  overcome: 


Probably  most  of  those  with 
an  interest  in  better  security 
measures  would  have  been  happy  if 
authority  came  from  anyone  - 
anyone  but  NSA,  that  is.... If  NSA 
is  going  to  smooth  the  waters, 
gain  the  trust  of  the  agency 
ADPers  whose  cooperation  is  vital 
to  this  program's  success  and 
hold  off  revision  minded 
congressmen,  it  will  have 
to. . .cooperate  with,  not  dictate 
to,  the  agencies,  it  will  have  to 
work  closely  with  Congress  and 
the  private  sector...  it  will 
have  to  operate  much  more  openly 
than  it  has  ever  done  before.... 9 


NSA  must  reemphasize  this  point:  it 
is  the  responsibility  of  each  agency, 
whether  defense  or  civil,  to  determine 
where  and  what  its  most  valuable  assets 
are,  and  what  the  consequences  of  exposure 
of  those  assets  would  mean  to  each 
agency. The  point  was  clarified  by  Assistant 
Secretary  of  Defense,  Donald  C.  Latham, 
when  he  testified  before  a  House 
subcommittee  that  the  directive: 


Does  not  make  NSA  the 
government's  oversighter  of  all 
civil  agencies. . .and  allow  them 
into  everybody's  computers  and 
tell  them  what  to  do. ...only 
where  appropriate  will  there  be 
any  assistance  to  the  civil 
Bector.  (The  assistance  from  NSA 
will  be  advice  and  information  in 
moBt  cases) ... .Implementation  of 
security  measures  is  the 
responsibility  of  the  federal 
departments  and  agencies,  not  the 
director  of  NSA  or  the  DoD. 10 

Sensitive  applications  must  be  certified 
and  accredited;  moreover,  the  process  of 
accreditation  is  an  integral  part  of  system 
security.  NSA's  role  is  to  provide 
guidance  to  departments  and  agencies. 

The  technical  experts  for  information 
security  are  available  at  NSA,  and  their 
knowledge  is  available  for  those  who  need 
help  with  computer  security  issues  in  their 
own  agencies.  Once  these  agencies,  the 
customers,  have  requested  computer  security 
assistance  from  NSA,  the  technical  experts 
must  keep  in  mind  that  their  job  is  to 
provide  a  service  to  those  customers.  Open 
lines  of  communication  and  a  professional 
attitude  on  the  part  of  the  NSA  experts 
will  add  much  to  the  effort  to  allay  the 
opposition's  fears.  A  large  part  of  the 


^"Security,"  GCH  editorial. 

10Eric  Fredell,  "Latham:  NSDD  145  Does 
Not  Restrict  Agency  Roles,"  Government 
Computer  News.  11  October  1985,  p.  16. 
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success  with  which  NSA  fulfills  its  mission 
as  the  leader  for  fostering  information 
security  is  dependent  upon  the  National 
Computer  Security  Center  (NCSC) ,  the 
organization  within  NSA  where  the  computer 
security  experts  work. 

The  Center 

With  NSDD  145,  the  Department  of 
Defense  Computer  Security  Center  (DoDCSCj 
became  the  National  Computer  Security 
Center;  however,  more  than  just  the  name  has 
been  changed.  The  Center's  mission  and 
responsibility  have  expanded  to  include  not 
only  the  DoD  but  also  the  civil  sector  (non- 
DoD  departments  and  agencies  of  the 
Executive  Branch)  of  the  Federal  Government 
where  appropriate.  (“Where  appropriate" 
means  having  systems  which  deal  with 
classified  information  or  other  national 
security-related  information.) 

The  Department  of  Defense  Computer 
Security  Center  (DoDCSC)  was  formed  in 
January,  1981,  with  a  major  goal  stated  in 
its  charter  of  “encouraging  widespread 
availability  of  trusted  computer  systems  by 
those  who  process  classified  or  other 
sensitive  information."  The  Center  has 
followed  a  strategy  to  improve  the  level  of 
data  security  in  computer  systems  throughout 
the  Department  of  Defense  by  various 
efforts.  The  strategy  has  been  to  emphasize 
the  need  to  install  state-of-the-art  secure 
"trusted"  systems  and  to  promote  the 
availability  of  those  systems. H 

The  task  of  the  new  mission  is  a 
tremendous  one,  but  the  effort  to  contact 
the  more  than  two  million  federal  employees 
who  need  to  become  aware  of  computer 
security  has  begun.  Two  upper  level 
management  representatives  from  the  Center 
have  been  circulating  to  various  federal 
agencies  in  an  attempt  to  open  the  lines  of 
communication  with  federal  managers.  The 
purpose  of  this  contact  has  been  to  provide 
information  about  the  Center  and  to  identify 
computer  systems  used  by  the  organization. 

A  new  "desk  officer"  program  has  also  begun 
with  the  purpose  of  providing  a  point  of 
contact  for  the  federal  agencies  in  their 
dealings  with  the  Center. 

It  is  obvious,  however,  that  the  lack 
of  both  resources  and  time  will  hinder  the 
Center's  ability  to  reach  two  million 
federal  employees.  The  enormity  of  the  task 
has  been  described  as  such  by  the  Center: 


Hu.S.,  Department  of  Defense,  DoD 
Computer  Security  Center,  Department  of 
Defense  Trusted  Computer  System  Evaluation 
Criteria.  CSC-STD-001-B3  (15  August  1983), 
P.  1. 


Although  NSDD  145  gives  NSA 
the  responsibility  for  automated 
information  systems  processing 
national  security  related 
information,  we  at  the  NCSC  will 
only  be  able  to  help  those  civil 
agencies  that  process  national 
security  related  information  and 
reguest  our  assistance. 12 

An  Office  Level  Management  Review 
(OLMR)  report  from  the  Applications  Systems 
Evaluations  Office  advocates  better  use  of 
existing  resources  to  address  the  NSDD  145 
tasks.  The  report  states  that  a  greater 
service  will  be  provided  by  giving  sound 
advice  and  support  to  many  projects  rather 
than  devoting  resources  to  long  term,  in- 
depth  analysis  of  a  few  systems.  The  best 
means  of  providing  support  to  many  is 
through  short  terra  undertakings.  Short 
term  efforts  will  benefit  not  only  the 
austomer,  but  also  the  Center. 13  Benefits 
to  the  customer  would  be  giving  the 
customer  a  service  that  is  much  needed,  and 
helping  the  customer  agency  build  its  own 
computer  security  expertise.  Benefits  to 
the  Center  would  be  building  the  Center's 
own  knowledge  base,  on-the-job  training  for 
new  computer  security  analysts,  and 
improving  public  relations  for  the  Center. 

Short  term  efforts  which  are  available 
for  both  DoD  and  civil  sector  customers 
include: 

1)  introductory  briefings: 
information  on  the  threats  and 
vulnerabilities  of  untruoted 
computer  systems  and  how  to 
reduce  risks,  presentation  of 
services  which  can  be  provided, 
and  educational  information; 

2)  technical  consultations: 
meetings  arranged  at  the  request 
of  the  customer  to  discuss 
particular  areas  of  concern  or 
general  computer  security  issues; 
and 

3)  Assessment  and  Advice  (ASA) 
studies:  on-site  technical 
analyses  in  support  of  any  phase 
of  a  project.1'* 


12Letter  to  Ms.  Jean  Smith  of  the 
Congress  of  the  United  States,  Office  of 
Technology  Assessment  from  the  National 
Computer  Security  Center,  (3  December 
1985) . 

^■office  Level  Management  Review 
(OLMR)  Summary  Report,"  10  December  1985, 
National  Computer  Security  Center. 

l^Briefing  at  the  National  Computer 
Security  Center,  Ft.  Meade,  MD,  22 
November  1985. 
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Again,  these  short  term  endeavors  must 
be  accelerated  to  create  the  most  benefit  to 
everyone  concerned.  In  particular, 
concentration  upon  the  Assessment  and  Advice 
effort  can  help  generate  the  greatest 
service  in  the  least  amount  of  time  to 
customers,  and  can  provide  the  Center's 
analysts  with  the  knowledge  of  systems 
currently  being  used  throughout  government 
agencies. 

AiA's 

An  Assessment  and  Advice  effort  is  not 
an  inspection,  certification,  or  risk 
analysis  but  rather  is  a  technical  analysis 
of  the  computer  security  posture  of  a 
particular  system  and  advice  to  the  customer 
about  vulnerabilities  of  the  system.  The 
A&A  will  identify  security  problems  and 
propose  reasonable  solutions  that  are 
achievable  by  the  customer.  In  addition  to 
immediate  suggestions  to  improve  computer 
security,  long  term  planning  suggestions  are 
provided. 15  These  suggestions  will  enable 
the  customer  to  assume  a  self-help  posture 
and  to  do  more  for  themselves  with  the 
Center  providing  counseling  and  tools  to 
help  thera.i-6 

Preliminary  Planning 

The  process  of  an  actual  A&A  is  a 
structured  operation.  Preliminary  planning 
begins  with  tasking  from  the  customer  in 
writing.  This  is  important  for  a  clear 
understanding  of  what  is  expected  and  what 
will  be  done  £>y  all  involved.  All 
"buzzwords"  must  be  clearly  defined, 
especially  the  fact  that  an  assessment  is 
not  a  full-fledged  certification.  The 
difference  between  these  two  technical 
analyses  of  systems,  one  analyst  explained, 
is  that  during  an  assessment,  the  computer 
security  evaluators  consider  the  system 
documentation,  procedures  and  personnel  as 
witness  to  the  security  of  the  system; 
whereas,  in  a  certification,  the  security  of 
the  system  must  be  proven,  tested  and 
validated  by  the  analysts, I7  Also  defined 
in  the  tasking  should  be  the  policy  or 
criteria  with  which  the  system  will  be 
compared.  Good  communication  from  the 
beginning  of  the  A&A  effort  is  very 
important. 

Acceptance  of  the  tasking  should 
clarify  in  writing  all  that  will  be  done  for 
the  customer  with  an  outline  of  the 
milestones  for  completing  the  process  of  the 
A&A.  The  customer  must  provide  information 
to  the  team  of  computer  security  analysts 
who  will  perform  the  A&A.  The  information 
needed  consists  of  documentation  and  manuals 
pertaining  to  the  system  to  be  assessed 


l5Ibid. 

l^OLMR  Summary  Report. 

l7Interview  at  the  National  Computer 
Security  Center,  Ft.  Meade,  MD,  4  September 
1985. 


and  a  questionnaire  or  survey  form  provided 
to  the  customer,  completed  promptly  by 
customer  personnel  knowledgeable  of  the 
system  and  returned  to  the  team  of  analysts 
at  the  Center.  A  generic  questionnaire  is 
currently  being  produced  by  analysts  in  the 
NCSC  for  use  in  a&a's.  Scheduling  for  the 
physical  site  visit  should  take  into 
consideration  the  preparation  and  review  of 
documentation  which  the  team  must  make. 
Classification  or  some  type  of  protection 
for  the  final  assessment  report  is 
necessary  for  the  confidentiality  of  the 
information  between  the  customer  and  the 
Center.  Some  customers  may  need  special 
charters  to  protect  the  information  from 
Freedom  of  Information  Act  inquiries.!0 
The  customer  should  be  advised  to  submit 
this  information  to  the  team  so  that  proper 
classification  procedures  can  be  followed. 

Having  accepted  the  task,  the  team  of 
analysts  must  keep  an  open  line  of 
communication  flowing  between  the  customer 
agency  and  the  Center.  It  is  very 
important  that  the  customer  furnish 
necessary  information  mentioned  as  quickly 
as  possible.  Without  the  documentation, 
manuals  and  the  completed  Burvey,  the 
evaluators  cannot  begin  to  familiarize 
themselves  with  the  system  to  be  assessed. 
Friendly  communication  will  encourage  the 
customer  to  deliver  the  materials  promptly. 
Once  the  materials  have  been  received,  a 
quick  call  or  note  keens  the  customer 
informed  and  lets  them  know  that  the  A&A  is 
progressing.  If  scheduled  milestones  or 
times  must  be  adjusted,  being  honest  with 
the  customer  and  not  making  promises  which 
cannot  be  kept  are  part  of  the  professional 
attitude  which  the  team  from  the  Center 
must  present.  The  team's  own  management 
must  be  informed  of  the  progress  of  the 
A&A,  with  what  the  team  is  doing  and  the 
time  frame  for  activities  planned. 

The  actual  job  at  hand  for  the 
assessment  team  is  to  become  familiar  with 
the  system  before  the  on-site  visit.  This 
preparation  allows  team  members  to  ask 
intelligent,  well-thought  out  questions  of 
site  personnel  and  prevents  the  necessity 
of  being  briefed  "from  scratch"  by  them. 

If  the  system  is  a  large  one,  tasks  might 
be  broken  down,  and  smaller  teams  formed  to 
concentrate  on  specific  technical  areas  and 
questions  concerning  these  areas.  A  point 
which  the  analysts  must  remember  during  the 
review  of  material  is  that  they  must  not 
make  premature  judgments  of  the  system 
which  are  unsupported  by  facts.  Unclear 
areas  in  documentation  may  easily  be 
explained  by  the  site  personnel  if  the 
analysts  have  not  already  formed  an  adverse 
opinion.  In  addition  to  computer  security 
knowledge,  each  member  of  the  A&A  team  must 
also  be 


10U.S. ,  Department  of  Commerce, 
National  Bureau  of  Standards,  Guideline  for 
Computer  Security  Certification  and 
Accreditation,  Federal  Information 
Processing  Standards  Publication  102 
(1983) ,  p.  64. 
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armed  with  skills  £or  briefings, 
interviewing,  and  report  writing.  Advanced 
preparation  by  all  team  members  benefits  the 
Center  by  presenting  a  professional 
appearance  to  the  customer.  Preparation 
thus  increases  the  customer's  confidence  in 
the  conclusions  and  recommendations  made  by 
the  Center's  computer  security  specialists 
during  the  physical  site  visit  and  in  the 
final  assessment  report. 

On-site  Visit 

The  on-site  visit  itself  is  of  short 
duration,  from  two  to  five  days.  Here,  the 
analysts  confer  with  customer  personnel  who 
know  the  system.  The  physical  site  visit 
gives  the  technical  team  the  opportunity  to 
examine  the  environment  in  which  the  system 
actually  operates  and  the  procedures  which 
personnel  follow  when  using  the  system.  The 
existence  of  most  physical  and 
administrative  controls  such  as  locks, 
guards  and  written  logbooks  can  be  seen 
during  the  visit.  Controls  internal  to  the 
machine  such  as  passwords  and  audit  trails 
can  be  shown  in  demonstrations  and  verified 
during  the  interviews  with  customer 
personnel.  The  intent  is  simply  to  show  the 
existence  or  lack  of  proper  controls. 

Active  penetration  testing  as  performed  in  a 
certification  effort  is  beyond  the  scope  of 
an  A&A.  The  visit  consists  of  several 
meetings  for  which  the  customer  must  arrange 
facilities  and  personnel. 

Generally,  the  visit  commences  with  an 
in-briefing.  The  in-brief  consists  of  a 
reconfirmation  of  the  tasking,  what  is  to  be 
done  during  the  visit,  and  general 
information  on  the  final  report.  Following 
this  briefing,  a  session  is  led  by  the 
customer  who  presents  a  general  overview  of 
the  system,  general  concerns  to  be  covered, 
a  visit  to  the  computer  and  terminal  areas, 
and  demonstrations  of  the  system. 

The  team  then  proceeds  to  interview  a 
variety  of  site  personnel,  whether  they  be 
users,  operators,  programmers,  managers,  or 
system  security  officers,  who  are 
knowledgeable  of  technical  aspects  of  the 
system.  Interviews  are  a  form  of 
interpersonal  communication  and  subject  to 
the  usual  problems  of  misunderstandings. 

Team  members  must  strive  to  prepare  well  for 
the  interview  so  that  they  already  know  the 
answers  to  the  questions  that  they  ask  and 
are,  therefore,  simply  verifying  information 
that  they  have  already  gathered.  The 
objective  of  the  reviewer  during  the 
interview  is  to  solidify  an  informed  opinion 
which  is  then  presented  in  the  final 
assessment  report.  Again,  advanced 
preparation  aids  the  team  in  obtaining 
proper  information  and  is  crucial  to  a 
successful  assessment. 20 


2°Ibid.,  p.  E-l. 


Once  all  interviews  have  taken  place, 
the  computer  security  team  meets  in  a 
private  session  to  discuss  their  findings 
and  concerns.  Since  a  team  decision  is  made 
concerning  the  security  posture  of  the 
system  which  they  have  just  examined,  the 
team  members  work  as  a  body  to  formulate  the 
decision  and  suggestions  which  are 
incorporated  into  an  out-brief  during  the 
visit,  and  finally,  in  the  written 
assessment  report. 

The  out-briefing  is  essentially  a  short 
form  of  the  final  report.  The  findings, 
conclusions  and  recommendations  determined 
by  the  technical  team  are  addressed.  Now, 
the  customer  knows  what  to  expect  in  the 
final  report;  there  will  be  no  surprises. 
Conclusion  of  the  on-site  visit  leaves  only 
paperwork  to  be  done  by  the  team. 

Final  Report 

The  final  assessment  report 
containing  information  gathered  during  the 
preparation  period  and  the  physical  site 
visit  is  written  and  delivered  to  the 
customer  as  quickly  as  possible.  Time 
frames  agreed  upon  in  initial  acceptance  of 
tasking  normally  target  completion  of  the 
report  within  30  -  60  days  after  the  site 
visit.  The  final  report  presents  an 
informed  opinion  of  the  security  posture  of 
the  system  and  computer  security  advice  to 
the  customer,  A  basic  part  of  the  report 
contains  information  on  how  the  system  meets 
the  policy  requirements  to  which  it  should 
conform.  Whether  the  requirements  be  a 
Criteria  class  or  the  customer's  own 
standards,  the  policy  to  consider  has  been 
agreed  to  by  management  in  the  initial 
tasking. 

Contents  of  the  report  consist  of  how 
the  current  system  "stacks  up"  to  the 
policy,  concerns  specific  to  the  system, 
possible  solutions  to  any  vulnerabilities 
found,  guidance  for  the  future  of  the 
system,  and  encouragement  for  the  customer 
to  continue  the  pursuit  of  computer 
security.  Each  of  these  points  should  be 
covered  during  the  out-brief  for  the 
customer,  and  the  final  report  just  expands 
on  those  points.  Classification  guidance 
for  the  report  which  was  specified  by  the 
customer  agency  must  be  followed.  Again, 
credibility  for  the  Center  grows  with  a 
timely  completion  of  the  report  and  its 
submission  to  the  customer. 

Conclusion 

The  Assessment  and  Advice  effort  is  an 
excellent  tool  which  the  Applications 
Evaluation  Office  can  employ  in  fulfilling 
the  mission  of  NSA  and  the  Center  defined  in 
NSDD  145  and  attempting  to  quell  the  fears 
of  those  who  oppose  that  directive. 
Continuation  of  these  short  term  projects 
will  quickly  aid  in  the  Center's  goal  of 
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being  viewed  as  a  "help  not  a  hindrance. "20 
In  addition,  the  knowledge  base  of  the 
Center  itself  will  also  benefit. 

"Organizations  are  always  involved  in 
some  process  of  transformation. .. .Healthy 
organizations  are  responsive  to  feedback, 
using  it  in  part,  as  a  basis  for  future 
messages,  policies  and  actions. *21 
Hopefully,  A&A  customers  will  be  open  to 
suggestions  that  the  Center  makes;  and 
hopefully,  from  those  customers  that  are 
served,  word  will  spread  that  the  Center  is 
doing  a  service  and  doing  it  well. 

Hopefully,  the  old  adage,  “Advice  most 
needed,  seldom  heeded,"  will  not  be  the 
standard  which  the  agencies  follow.  A 
willingness  to  cooperate  and  work  together 
helps  everyone  get  on  the  right  track  toward 
information  security. 


Summary 

“All  organizations  must  remain 
relatively  open  in  order  to  survive. 
Organizations  cannot  exist  as  static 
systems. ... "22  This  fact  is  evident  even 
within  an  organization  as  large  as  the 
federal  government  of  the  United  States.  As 
the  National  Security  Agency  and  the 
National  Computer  Security  Center  address 
the  critical  need  for  computer  security  in 
the  information  systems  of  federal  agencies, 
it  is  hoped  that  those  agencies  will  have 
the  ability  to  accept  the  advice  which  they 
are  given  and  to  facilitate  needed  changes. 

Real  security  for  electronic 
information  does  not  result  from 
rules  on  pieces  of  paper, 
assignments  of  people,  hardware 
facilities  or  software  systems.... 
Security  depends  on  people's  being 
willing  to  comply... to  the  means 
selected  for  protection. 23 

NSA  and  the  Center  can  ease  the 
resistance  to  change  by  employing  aboveboard 
procedures  and  by  quickly  giving  help  where 
needed.  Short  term  efforts,  in  particular 
the  Assessment  and  Advice  program,  are  the 
best  means  for  accomplishing  this  goal. 
Computer  security  in  the  information  systems 
of  the  federal  government  not  only  can 
happen,  it  must  happen,  for  the  security  of 
the  nation  is  dependent  upon  it. 


20OLMR  Summary  Report. 

21Patricia  Hayes  Bradley  and  John  E. 
Baird,  Jr. ,  Communication  for  Business  and 
the  Professions.  2nd  ed.  (Dubuque:  William 
C.  Brown  Co.  Publishers,  1983) ,  p.  18  -  21. 

22ibid,  p.  20. 

23james  A.  Schweitzer,  Managing 
Information  Security;  A  Program  for  the 
Electronic  Information  Age.  (Boston: 
Butterworth,  (Publishers)  Inc.,  1982),  p.  2. 
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The  highest  level  requirements  on  a  secure 
computing  system  are  usually  stated  in  terms 
of  information,  that  is,  they  state  that 
certain  information  must  not  be  obtained  by 
certain  individuals  on  the  system.  Formal 
models  of  computer  security  to  date  have 
concerned  themselves  largely  with 
restrictions  on  the  movement  of  data.  While 
these  restrictions  capture  part  of  the  high 
level  requirements  of  secure  systems,  they  do 
not  capture  all  of  them,  as  witnessed  by  the 
fact  that  there  is  a  distinction  made  between 
"formal  modeling"  and  "covert  channel 
analysis".  True  formal  verification  of  a 
secure  system  would  incorporate  the  security 
violations  usually  covered  by  "covert  channel 
analysis"  into  the  formal  model  of  the 
system. 


second  answer  in  a  little  more  detail. 

For  the  purpose  of  this  discussion  we  will 
say  an  abstract  state  machine  consists  of : 

1  .  A  set  of  states 

2.  A  set  of  possible  initial  states 

3 .  A  set  of  s£a£e  transformations .  by 
which  we  mean  a  function  from  states  to 
states. 

The  set  of  states  is  usually  defined  by 
giving  a  set  of  state  variables,  each  of 
which  has  a  certain  type;  a  state"  is  then 
an  assignment  of  each  state  variable  to  a 
value  in  its  type. 


In  this  paper  we  present  a  simple  model  of 
information  and  inference,  give  a  generic 
instantiation  of  the  model  to  state  machines, 
apply  the  instantiation  to  a  simple  example, 
and  discuss  the  relationship  between  the 
state  machine  instantiation  and  the 
Goguen-Meseguer  non-interference  model. 

What  is  information?  What  does  it  mean  to 
infer  information  from  other  information?  We 
will  start  with  a  few  naive  answers  to  these 
questions. 


1  Information 


How  do  we  imagine  such  an  abstract  machine 
actually  "running"?  We  imagine  the  machine 
starting  out  in  one  of  the  possible  initial 
states,  and  then  changing  state  over  the 
course  of  time  as  various  state 
transformations  are  applied.  For  each 
possible  initial  state  and  each  sequence  of 
transformations  applied,  we  get  a  sequence  of 
states  that  the  machine  passes  through. 
Thus,  an  abstract  machine  defines  a  set  of 
possible  sequences  of  states  that  the  machine 
can  pass  through.  We  will  call  these 
sequences  possible  execution  sequences.  We 
will  regard  time  as  being  measured  in  terms 
of  tne  number  of  state  changes  the  machine 
has  passed  through,  so  "state  at  time  0" 
refers  to  the  initial  state  of  the  machine, 
"state  at  time  1"  refers  to  the  state  of  the 
machine  after  one  application  of  a  state 
transformation,  and  so  on. 


In  answer  to  the  first  question,  someone  who 
was  used  to  thinking  in  terms  of  formal 
specifications  of  systems  might  answer  "the 
values  of  some  collection  of  state 
variables".  What's  wrong  with  this  answer? 
One  problem  with  this  answer  is  that  it's  not 
general  enough.  Most  instances  of 
information  channels  involve  observing  the 
values  of  some  collection  of  state  variables 
over  the  course  of  time;  no  one  instantaneous 
value  contains  the  information  transmitted. 
Suppose  we  amended  the  above  answer  to 
"information  is  the  history  of  some 
collection  of  state  variables"  where 
"history"  means  "history  f'-om  time  0  to  some 
time  t" .  One  problem  with  cihis  second  answer 
is  that,  in  order  to  apply  it  tc  a  system, 
the  system  must  be  expressed  au  a  state 
machine.  Not  only  does  this  force  us  to  use 
a  certain  representation,  but  our  analysis  of 
information  in  the  system  might  be  unduly 
sensitive  to,  say,  what  state  variables  we 
choose.  What  we  wish  to  do  at  this  point  is 
generalise  the  second  answer  so  that  it's 
independent  of  how  the  system  io 
represented.  To  do  this,  we'll  look  at  the 


Given  a  collection  of  state  variables  V  and  a 
time  T,  what  do  we  mean  by  "the  history  of 
the  state  variables  in  V  from  time  0  to  time 
T"?  This  "history"  is  actually  a  function 
(call  it  h)  whose  domain  is  the  set  of 
possible  execution  sequences.  Given  a 
possible  execution  sequence  S,  h(S)  is  a 
finite  sequence  of  length  T  +  1  such  that; 

1.  The  ith  entry  of  h(S)  is  an  assignment 
of  each  state  variable  in  V  to  a  value 
in  its  type. 

2.  For  each  state  variable  v  in  V,  the 
value  assigned  to  v  by  the  ith  entry  of 
h(S)  is  the  same  value  assigned  to  v  by 
the  ith  entry  of  S. 

In  other  words,  H  takes  the  first  T  +  1 
entries  of  S  and  extracts  out  the  assignments 
of  the  variables  in  V. 

Ne  generalize  the  above  scheme  in  the 
following  way:  we  represent  a  system  as  a  set 
of  possible  worlds;  this  corresponds  to  the 
set  of  possible  execution  sequences  for  an 
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abstract  state  machine.  A  particular  "piece 
of  information"  about  the  system  is 
represented  as  a  function  whose  domain  is  the 
set  of  possible  worlds;  we  will  call  such 
functions  information  functions.  An 
information  function  can  be  thought  of  as  a 
certain  "view"  of  the  system;  in  a  given 
possible  world  w,  an  information  function 
returns  what  is  "seen"  of  w  by  someone 
"looking  at"  the  information  function. 


2  Inference 


We  now  return  to  the  second  question  posed  at 
the  beginning  of  the  section;  what  does  it 
tean  to  infer  information  from  other 
information?  In  terms  of  the  formalism 
developed  above,  what  does  it  maan  to  infer 
something  about  the  value  of  one  information 
function  from  the  value  of  another 
Information  function?  To  answer  this 
question,  we  will  imagine  a  user  who; 

1.  knows  what  the  set  of  possible  worlds  W 
is  (this  corresponds  essentially  to 
knowing  how  the  system  is  designed); 

2.  knows  what  information  function  he  is 
seeing  (call  it  fl )  (this  corresponds 
to  the  user  knowing  what  his  interface 
to  the  system  is.  If,  for  example,  a 
user  could  3ee  a  terminal  but  had  no 
idea  how  the  output  appearing  on  the 
terminal  was  being  generated,  he  would 
be  able  to  deduce  very  little  about  the 
system. ) ; 

3.  knows  what  information  function  he 
wishes  to  deduce  something  about  (call 
it  f 2 ) ; 

4.  is  “in"  some  possible  world  w,  and 
knows  the  value  of  fl(w)  (call  it  x). 

What  can  the  user  infer  about  f2(w)?  Since 
he  knows  that  fl(w)  »  xr  he  can  deduce  that  w 
is  in  the  set  of  all  possible  worlds  y  such 
that  fl(y)  «  x.  Call  this  set  S.  On  the 
basis  of  the  above  knowledge,  ail  the  user 
can  deduce  about  w  is  that  it  is  in  S.  From 
this,  he  can  deduce  that  f2(w)  is  in  the 
image  of  S  under  f2.  Call  this  image  T»  If 
there  is  some  value  z  in  the  range  of  £2  that 
is  achieved  in  some  possible  world  but  which 
is  not  in  T,  then  the  user  has  actually 
gained  some  information  about  f2(w),  namely, 
he  at  least  knows  that  it  is  not  equal  to  z. 
If,  on  the  other  hand,  every  value  z  in  the 
range  of  f2  that  is  achieved  in  some  possible 
world  is  in  T,  then  the  user  knows  nothing 
more  about  f2  than  he  could  have  inferred  on 
the  basis  of  knowing  W  and  f2  alone.  This 
leads  us  to  the  following  definition; 

Given  a  set  of  possible  worlds  W 
and  two  functions  fl  and  f2  with 
domain  W,  we  say  that  information 
flows  from  f1_  to  f2  if  and  only  if 
there  exists  some  possible  world  w 
and  some  element  z  in  the  range  of 
f2  such  that  z  is  achieved  by  f2  in 
some  possible  world  but  in  every 


possible  world  w'  such  that 
fl(w')  -  fl(w),  f2(w')  .Js  not  equal 
to  z. 

Having  given  this  somewhat  complicated  but 
reasonably  motivated  definition,  the  first 
thing  we  will  do  is  note  that  it  is 
equivalent  to  a  much  simpler  statement. 

Proposition;  Given  W,  fl  and  f2  as  above, 
information  does  not  flow  from  fl  to  f2  if 
and  only  if  the  function  fl  x  f2  from  W  to 
the  cross  product  of  the  images  of  fl  and  f2 
is  onto. 

Proof ;  Suppose  information  does  not  flow  from 
fl  to  f 2;  we  wish  to  show  that  fl  x  f2  is 
onto  image(fl)  x  image(f2).  Let  (x,y)  be  an 
element  of  the  cross  product.  Since  x  is  in 
the  image  of  fl ,  there  exists  a  possible 
world  wl  such  that  x  *  fl(wl).  Likewise, 
there  exists  a  possible  world  w2  such  that 
y«f2(w2).  If  we  take  the  negation  of  the 
above  definition  with  w  *  wl  and  z  «  y,  we 
get  that  there  must  exist  a  possible  world  w' 
such  that  fl(w')  »  fl(wl)  »  x  and 
f2(w‘)  «  y.  In  other  words, 
(fl  x  f 2 ) ( w * )  ■  (x,y).  Since  (x,y)  was 
arbitrary,  fl  x  f2  is  onto. 

Conversely,  suppose  fl  x  f2  is  onto.  Let  w 
be  a  possible  world  and  z  an  element  of  the 
range  of  f2  that  is  acheived  by  £2  in  some 
possible  world  (in  other  words,  z  is  an 
element  of  image(f2)).  Then  (fl(w),z)  is  an 
element  of  image(fl)  x  image(f2)  and  so  there 
exists  a  possible  world  w'  such  that 
(fl  x  f 2)  (w* )  -  ( f  1  ('••), z ) ,  i.e. 
fl (w* )  -  fl (w)  and  f2lw’ )  »  z. 

Corollary;  the  information  flow  relation  is 
symmetric. 

The  corollary  seems  somewhat  surprising  at 
first  glance,  since  information  flow  is  not 
usually  thought  of  as  being  necessarily  a 
two-way  street.  However,  consider  the 
following  scenario:  a  system  is  designed  so 
that  every  character  which  is  typed  at 
keyboard  K  is  echoed  to  screen  S.  Let  fl  be 
the  information  function  which,  given  a 
possible  world,  returns  the  sequence  of  all 
characters  typed  on  K  in  that  world,  and  let 
f2  be  the  information  function  which,  given  a 
possible  world,  returns  the  sequence  of 
characters  displayed  on  S  in  that  world. 
Information  is  obviously  being  transferred 
from  K  to  S ,  and  so  we  would  expect  to  find 
that,  according  to  the  definition  above, 
information  flows  from  fl  to  f2.  This  is 
exactly  what  we  do  find.  By  the  corollary, 
we  will  also  find  that  information  flows  from 
f2  back  to  fl  ,  i.e.,  it  will  find  that, 
knowing  the  value  of  fl ,  one  can  infer 
something  about  f2.  But  this  is  in  fact 
true)  If  one  knows  the  design  of  the  system, 
and  one  knows  what  has  been  typed  at  X,  one 
knows  something  about  what  shows  up  on  S.  A 
problem  arises,  however,  if  we  try  bo  assign 
security  levels  to  information  functions  and 
require  that  information  always  flow  "up."  If 
we  assign  K  a  level  "lo"  (say,  because  only 
"lo"  individual j  are  allowed  to  type  at  it) 
and  S  a  level  "hi"  (say,  because  only  "hi" 
people  are  allowed  to  view  it),  we  will  find 
a  flow  in  both  directions,  violating  the 


176 


security  requirement,  despite  the  fact  that 
the  system  as  described  seems  secure.  The 
problem  is  not  in  the  definition  of 
information  flow  but  rather  in  the  choice  and 
labeling  of  information  functions.  S  may  be 
a  "hi"  terminal,  but  the  information  it  gets 
from  K  is  not  "hi"  information,  and  thus 
should  not  be  labeled  as  "hi."  Actually,  the 
only  information  which  should  be  labeled  as 
"hi"  is  information  which  comes  from  high 
sources.  We  will  discuss  thYs  further  below 
when  we  instantiate  the  information  model  to 
state  machines. 


3  Security  Conditions 


We  now  have  a  model  of  information  and  a 
definition  of  information  flow.  What  we  need 
to  complete  the  model  is  a  definition  of 
"secure".  Informally,  a  system  is  secure  if 
nobody  can  get  information  he's  not  entitled 
to.  How  can  we  express  this  in  the  above 
formalism? 

First  of  all,  each  "piece  of  information" 
which  has  restrictions  on  who  may  "get"  it  is 
represented  by  an  information  function. 
Second,  each  "entity"  on  the  system  which  has 
restrictions  on  what  information  it  can  "get" 
is  represented  by  an  information  function 
corresponding  to  the  entity's  "view"  of  the 
system.  We  will  denote  the  set  of 
information  functions  corresponding  to  pieces 
of  information  and  entities  by  IF.  We 
represent  the  restrictions  on  which  entities 
are  entitled  to  "get"  which  pieces  of 
information  by  a  binary  relation 
"legal_to_get"  on  IF. 

How  can  we  formally  express  the  notion  of  an 
entity  E  "getting"  a  piece  of  information  I? 
If  fl  is  the  information  function 
corresponding  to  E  and  f2  is  the  information 
function  corresponding  to  I,  we  interpret  "E 
‘gets’  I"  to  mean  "information  flows  from  f2 
to  fl". 

Under  these  interpretations,  the  informal 
statement  of  security  given  at  the  beginning 
of  the  section  is  formalized  as 

For  all  fl  and  f2  in  IF,  if 
information  flows  from  f 2  to  fl 
then  legal_to_get ( f 1 , f 2 ) 

Readers  familiar  with  formal  computer 
security  may  at  this  point  be  asking  "Where 
are  the  security  levels  in  this  model?"  The 
answer  is  that  security  levels  are  a 
particular  instance  of  the  model.  We  could 
assign  security  levels  to  the  functions  in  IF 
and  define  legal_to._get(f1 ,f2)  if  and  only  if 
the  level  of  fl  is  less  than  or  equal  to  the 
level  of  f 2.  This  is  just  one  possible  way 
of  defining  l@gal_to_get;  the  model  allows 
for  others,  e.g.  discretionary  access 
restrictions. 


4  Summary  of  the  Model 


In  this  section  we  summarize  the  information 
model  briefly.  An  instance  of  the  model 
consists  of: 

1 .  A  set  W  of  possible  worlds 

2.  A  set  IF  of  functions  with  domain  W 

3.  A  binary  relation  on  IF,  legal_to_get 

Such  an  instance  is  secure  if  and  only  if  for 
every  fl  and  f2  in  IF,  if  information  flows 
from  f 2  to  fl  then  legal_to_get(f1  ,f2)  (where 
information  flow  between  functions  with 
domain  W  is  defined  as  above). 


5  State  Machine  Instantiation 


In  this  section,  we  instantiate  the 
information  model  given  above  to  a  state 
machine.  We  begin  by  defining  what  we  will 
mean  by  a  state  machine. 


5.1  State  Machines 

"State  machine"  will  mean  a  non-deterministic 
finite  automaton  with  null  moves  except  that 
the  state  space  of  the  automaton  is  not 
required  to  be  finite.  In  other  words,  a 
state  machine  consists  of  a  set  of  states,  a 
non-empty  set  of  initial  states,  an  alphabet, 
and  a  set  of  "arrows."  Each  "arrow"  starts  at 
one  state  and  points  to  another;  an  arrow  may 
be  labeled  with  a  single  element  of  the 
alphabet  or  it  may  be  unlabeled.  The 
"operation"  of  the  machine  is  to  start  at  an 
initial  state  and  change  state  in  steps,  with 
each  state  change  accompanied  by  one  or  no 
letters  of  the  alphabet. 

We  now  add  a  few  extra  structures  and  some 
additional  axioms.  First  of  all,  at  this 
point  we  will  stop  using  the  word  "alphabet" 
and  refer  to  the  set  we  formerly  called  the 
alphabet  as  the  signals  of  the  state 
machine.  The  signals  of  the  machine  are 
partitioned  into  the  input  signals  and  the 
output  signals .  There  is  also  a  set  of 
security  levels,  partially  ordered  by  a 
relation  <■,  and  a  function  from  signals  to 
levels. 

We  require  that  for  every  state  of  a  state 
machine  and  every  input  signal,  there  is  an 
arrow  which  starts  at  the  given  state  and  is 
labeled  with  the  given  signal.  In  other 
words,  it  is  always  possible  for  a  state 
machine  to  receive  a  given  signal  (even  if 
its  only  response  is  to  remain  in  its  former 
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state).  We  also  require  that  for  every  state 
of  the  machine  there  is  an  arrow  which  starts 
at  the  given  state  which  is  not  labeled  with 
an  input  signal.  In  other  words,  it  is 
always  possible  for  the  state  machine  to  "go 
ahead",  even  in  the  absence  of  an  input. 


5.2  Instantiating  the  Information  Model 

We  wish  to  interpret  the  information  model  in 
terms  of  state  machines.  In  other  words,  we 
want  to  give  a  procedure  which  takes  a  state 
machine  and  returns  the  corresponding 
information  model.  Security  for  the  state 
machine  is  then  defined  simply  as  security 
for  the  corresponding  information  model. 
Thus,  we  need  to  give  a  procedure  which, 
given  a  state  machine,  gives  a  corresponding 
set  of  possible  worlds,  a  set  of  information 
functions  for  that  set  of  worlds,  and  a 
binary  relation  on  those  information 
functions  defining  what  information  flows 
between  them  are  legal.  We  now  describe  this 
procedure. 

Suppose  we  have  a  state  machine  described  by: 

1 .  A  set  of  states  S 

2.  A  set  of  initial  states  I 

3.  A  set  of  input  signals  X 

4.  A  set  of  output  signals  Y 

5.  A  set  of  "arrows"  A  (we  won't  give  a 
completely  formal  definition  of  what  an 
"arrow"  is,  as  it  would  be  more 
obfuscatory  than  anything  else). 

6.  A  set  of  levels  L  with  partial  ordering 


7.  A  function  from  X  U  Y  to  L 

The  set  of  possible  worlds  we  associate  with 
this  machine  is  the  set  of  finite  sequences 
K  »  {  H[i]  |  0  <=  i  <=  length (H)  -  1  )  such 
that : 

1.  Each  H[i]  is  either  a  state  or  a  signal 

2.  No  two  consecutive  entries  in  the 
sequence  are  both  signals 

3.  HI  0 ]  is  an  initial  state 

4.  If  Hli)  and  H[i+1]  are  states,  there  is 
an  unlabeled  arrow  from  H[i]  to  H[i+1] 

5.  If  H[i]  is  a  state  and  H[i+1]  is  a 
signal,  there  is  an  arrow  starting  at 
H[i]  labeled  with  H(i+1] 

6.  If  H[i]  is  a  state,  H[i  +  1]  is  a  signal 
and  H[ i+2  ]  is  a  state,  there  is  an 
arrow  from  H [ i ]  to  H[i+2]  labeled  with 
H[ i  +  1  1 

There  is  actually  an  important  reason  why  we 
have  chosen  finite  sequences  rather  than 
infinite  sequences  as  our  possible  worlds. 
Under  tha  above  instantiation,  a  possible 
world  is  literally  a  possible  run  of  the 
system  i 2  a.  given  point  in  time.  Thus, 


any  inference  made  in  such  a  world  can  only 
take  into  account  the  information  about  the 
world  which  has  manifested  itself  up  to  the 
point  in  time  being  considered.  We  can  think 
of  such  finite  worlds  as  being  initial 
segments  of  some  real,  complete  possible 
world  (i.e.  an  infinite  sequence),  but  any 
inference  must  be  made  at  some  finite  point 
in  it.  This  choice  literally  affects  whether 
some  systems  are  formally  secure  or  not,  and 
the  choice  we  have  made  seems  to  make  the 
"right"  systems  formally  secure. 

For  each  level  1  in  U ,  we  define  two 
information  functions  over  the  possible 
v  orlds  defined  above: 

1.  view( 1)  is  the  function  which,  given  a 
possible  world  H  as  above,  returns  the 
subsequence  of  H  consisting  of  those 
signals  s  whose  levels  are  <=  1 

2.  hidden  from(l)  is  the  function  which, 
given  a  possible  world  H,  returns  the 
subsequence  of  H  consisting  of  those 
input  signals  s  whose  levels  are  not  <= 
1 

Finally,  we  specify  that  it  is  illegal  for 
information  to  flow  from  hidden_from( 1 )  to 
view(l)  for  any  1. 

This  choice  of  information  functions  and 
illegal  flows  is  based  on  the  following 
picture:  there  is  a  collection  of  "entities" 
external  to  the  machine  which  interact  with 
it,  and  each  of  these  entities  has  a  level. 
It  is  assumed  that  each  entity  only  "knows" 
some  signals  going  into  and  coming  out  of  the 
machine,  and  that  an  entity  of  level  1  is 
allowed  (by  procedural  safeguards  or 
whatever)  to  see  at  most  all  of  the  signals 
that  go  into  or  out  of  the  machine  whore 
levels  are  <=  1.  The  choice  of  illegal  flows 
simply  reflects  the  policy  that  an  entity  of 
level  1  should  not  be  able  to  deduce  from 
what  it  is  legal  that  he  see  anything  about 
what  it  is  not  legal  that  he  see.  Notice 
that,  according  to  the  instantiation,  there 
is  nothing  wrong  per  ss.  in  a  low  level  entity 
being  able  to  deduce  a  high  level  output 
signal.  If  a  high  level  output  signal  is 
unconnected  to  any  high  level  input  signals, 
then  it  is  not  a  violation  of  security  for  a 
low  level  entity  to  see  it.  If,  on  the  other 
hand,  such  a  high  level  output  has  some 
connection  to  a  high  level  input,  then  this 
connection  will  presumably  be  reflected  as  an 
information  flow  and  thus  an  information  flow 
will  be  found  from  the  high  inputs  to  the  low 
entity,  violating  the  policy  as  stated. 


6  An  Example 


In  this  section  we  give  a  simple  example  of 
the  use  of  the  state  machine  instantiation  of 
the  information  model.  We  will  first 
describe  the  machine  informally. 

The  machine  is  a  simple  message-passing 
system.  It  consists  of  a  collection  o£ 
"ports"  and  a  queue  of  "message  entries." 
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lvl(p)  <=  1. 


Each  port  is  labeled  with  a  security  level 
indicating  what  level  entities  external  to 
the  machine  can  access  the  port.  Ports  can 
input  messages  to  the  machine,  which  get  put 
on  the  queue  in  a  message  entry.  The  message 
entry  also  contains  the  information  of  which 
port  the  message  came  from.  The  intended 
destination  of  the  message  is  contained  in 
the  message.  When  a  message  entry  comes  to 
the  head  of  the  queue,  one  of  two  actions  is 
taken:  (1)  if  the  level  of  the  destination 
port  is  greater  than  or  equal  to  the  level  of 
the  source  port,  the  message  is  output  to  the 
destination  port  and  the  message  entry  is 
removed  from  the  queue;  (2)  otherwise,  the 
message  entry  is  removed  from  the  queue  and 
no  output  occurs. 

We  now  describe  the  above  machine  formally. 
We  denote  the  set  of  ports  by  P,  thu  set  of 
messages  by  M,  the  set  ol  security  levels  by 
L,  the  partial  ordering  on  L  by  <»,  the 
function  which  takes  n  pm I  and  returns  its 
level  by  lvl  (a  function  from  P  to  L),  and 
the  function  wtiich  takes  a  message  and 
returns  its  destination  by  dest  (a  function 
from  M  to  P). 

The  statu  of  the  machine  i-s  a  sequence  of 
pairs  (m,p)  where  m  is  in  M  and  p  is  in  P. 
The  initial  state  of  the  machine  is  the  empty 
sequence - 

A  signal  of  the  machine  is  a  triple  (m,p,x) 
where  m  ia  in  M,  p  is  in  P  and  x  is  in  the 
set  { input, output } .  Such  a  signal  Is  an  input 
signal  if  x  is  "input"  and  an  output  signal 
if  x  ia  "output".  If  x  is  "input",  p  is  the 
port  from  which  the  signal  came.  If  x  is 
"output",  p  is  the  port  to  which  the  signal 
goes.  The  level  of  a  signal  (m,p,x)  ia 
lvl (p) . 

The  arrows  of  the  machine  are  as  follows: 

For  each  state  s,  each  m  in  M  and  each  p 
in  P,  let  s'  be  the  sequence  s  with  the 
pair  (m,p)  prepended;  there  is  an  arrow 
from  s  to  s’  labeled  with  (m,p, input). 

For  each  state  s,  each  m  in  M  and  each  p 
in  P,  let  s'  1  be  the  sequence  s  with  the 
pair  (m,p)  appended: 

*  If  lvl(p)  <=  lvl(dest(m) ) ,  there  is 
an  arrow  from  s'1  to  a  labeled  with 
(m,dest(m) , output) , 

*  If  lvl(p)  is  not  lvl (dest(m) ) , 
there  is  an  unlabeled  arrow  from 
s'1  to  a . 

There  is  an  unlabeled  arrow  from  the 
empty  sequence  to  itself. 

We  will  now  prove  that  this  machine  meets  the 
security  condition  of  the  state  machine 
instantiation  ol:  the  information  model. 

Fix  a  level  1  in  i,,.  We  wish  to  prove  that  no 
information  flows  from  hidden_from( 1 )  to 
view(l).  First,  we  will  define  a  function  R 
from  states  to  states  as  follows:  if  s  is  a 
state  (i.e.  a  sequence  of  message-port 
pairs),  R(s)  is  the  subsequence  of  s 
consisting  of  the  entries  (m,p)  such  that 


We  want  to  examine  what  happens  to  a  possible 
world  of  the  machine  (i.e.  a  finite  sequence 
of  states  and  signals  meeting  the  conditions 
described  in  the  previous  section)  when  we 
apply  R  to  every  state  in  it.  To  do  this,  we 
must  examine  the  effect  of  R  on  the  initial 
state  of  the  machine  and  the  pairs  of  states 
at  the  ends  of  the  various  arrows. 

The  initial  state  of  the  machine  is  the  empty 
sequence,  and  R  of  the  empty  sequence  is  the 
empty  sequence.  Thus,  R  of  the  initial  state 
is  the  initial  state. 

Suppose  there  is  an  arrow  from  s  to  s' 
labeled  with  (m,p, input);  s'  must  therefore 
be  s  with  (m,p)  prepended.  What  do  R(s)  and 
R(s’)  look  like?  If  lvl(p)  <=  1,  R(s’)  is 
R(s)  with  (m,p)  prepended,  and  so  there  is  an 
arrow  from  R(s)  to  K ( 3 ' )  labeled  with 
(m, p, input).  If  lvl(p)  is  not  <=  1,  R(s) 
equals  R(s').  In  other  words,  if  the  arrow 
corresponds  to  an  input  signal  of  level  .1, 
the  states  at  the  ends  of  the  arrow  are 
mapped  to  states  at:  the  ends  of  an  arrow 
corresponding  to  the  same  input  signal;  in 
tills  case  we  will  say  that  R  "preserves"  the 
arrow.  If  the  arrow  corresponds  to  an  input 
signal  whose  level  is  not  <**  1,  the  states  at 
the  end  of  the  arrow  are  mapped  to  the  same 
state;  in  this  case  we  will  say  that  R 
"masks"  the  arrow. 

Suppose  there  is  an  arrow  from  s''  to  s 
labeled  with  (m,dest(m) , output) .  s'1  must 
therefore  be  s  with  (m,p)  appended  for  some  p 
such  that  lvl(p)  <=■  lvl  (dest  (in) ) .  In  this 
case,  if  lvl(p)  <=  1  then  R(s'')  is  H(s)  with 
( m , p )  appended,  and  there  is  an  arrow  from 
R(s’  '  )  to  R(s)  labeled  with 
(m,dest(m) ,output).  Again,  we  say  thut  R 
preserves  the  arrow.  If  lvl(p)  is  not  <«=  1, 
R( s  1  1  )  equals  R ( s ) ,  and  we  say  that  R  masks 
the  arrow. 

Suppose  there  is  an  unlabeled  arrow  from  s'1 
to  s.  There  are  two  possibilities  for  s'* 
and  a.  First,  s1'  and  s  can  both  be  the 
empty  sequence,  in  which  case  R(s'')  =*  R(s)  »= 
the  empty  sequence  and  we  say  that  R 
preserves  the  arrow.  Second,  s'*  can  be  i; 
with  (m,p)  appended  for  some  p  such  that 
lvl(p)  is  not  <=  lvl  (dest(m) ) .  In  this  case,, 
if  lvl(p)  <=  1  then  H(s*')  is  R(s)  with  (m,p) 
appended,  and  there  is  an  unlabeled  arrow 
from  R( a ' 1 )  to  R(s).  Again,  we  say  R 
preserves  the  arrow.  If  lvl(p)  is  not  <=  1, 
H(s‘‘)  equals  R(s)  and  we  say  that  R  masks 
the  arrow. 

What  happens  when  we  take  a  possible  world  H 
and  apply  R  to  every  state  in  it?  We  can 
think  of  H  informally  as  consisting  of  a 
.sequence  of  arrows,  with  the  first  arrow 
starting  at  the  initial  state  and  with  the 
ending  and  starting  states  of  consecutive 
arrows  matching.  Each  such  arrow  will  either 
be  preserved  by  R  or  masked  toy  R,  If  we 
"throw  away"  the  arrows  that  are  masked  by  R, 
we  get  a  new  possible  world  of  the  machine. 
Call  this  world  RH.  What  iu  the  relationship 
between  RH  and  H?  Rfl  is  essentially  H  with 
all  input  signals  whose  levels  are  not  <=  1 
removed.  In  addition,  all  outputs  and  state 
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changes  resulting  from  such  signals  (i.e. 
being  queued,  being  dequeued)  are  also 
removed.  On  the  other  hand,  all  of  the  input 
and  output  signals  of  level  <=1  are  the  same 
(the  proof  of  this  relies  on  the  fact  that 
the  machine  only  allows  signals  from  a  given 
port  to  be  output  to  ports  of  equal  or 
greater  level).  In  other  words,  view(l)(RH) 
=  view(l)(H)  while  hidden_from( 1) (RH)=  the 
null  sequence.  Given  any  sequence  s  of  input 
signals  of  level  not  <=1,  we  can  add  them  on 
to  the  end  of  RH  to  get  a  possible  world  H‘ 
such  that  view(l)(H')=  view(l)(RH)  and 
hidden _from( 1 ) (H ' ) “S .  Since  H  was  arbitrary, 
this  shows  that  for  any  value  vl  in 
Image (view(l) ) ,  any  any  value  v2  in 
image (hidden  from(l)),  there  exists  a 
possible  world  H’  such  that  view(l)(H')=  vl 
and  hidden_f rom( 1 ) ( H ' ) »  v2.  In  other  words, 
view(l)  x  hidden_f rom( I )  is  onto 
image (view(l) )  x  image (hidden_f rom( 1) )  so 
there  is  no  information  flow  between  them. 
Since  1  was  arbitrary,  this  proves  the 
security  condition. 


7  Connection  with  the  Goguen-Meseguer  Model 


We  can  think  of  the  above  proof  as  taking 
place  in  two  stages.  We  start  with  an 
arbitrary  possible  world  H,  and  we  show  that: 

1  .  We  can  replace  II  by  RH  sc  that  there  are 
no  signals  of  level  not  <*  1,  without 
changing  any  signal  of  level  <=  1. 

2.  We  can  replace  RH  by  H*  to  make  the 
signals  of  level  not  <-  1  anything  we  want, 
without  changing  any  signal  of  level  <=  1. 

The  first  step  looks  something  like  a  proof 
of  a  non-interference  condition  as  in  the 
Goguen-Meseguer  model,  i.e.  it  shows  that 
the  inputs  of  entities  of  level  not  <=1  can 
be  deleted  without  effecting  what  is  seen  by 
entities  of  level  <  ■  1 .  What  is  the 
relationship  between  the  state  machine 
instantiation  of  the  information  model  and 
the  Goguen-Museguer  non-interference  model? 

First  of  all,  by  "The  Goguen-Meseguer  model" 
we  will  hereinafter  mean  the  model  as  set 
for  .h  in  [1],  We  will  only  consider  what  are 
referred  to  as  "static  systems"  in  [1).  The 
first  problem  we  encounter  in  comparing  our 
state  machine  instantiation  with  the 
Goguen-Meseguer  Model  is  that  the 
Goguen-Meseguer  model  uses  a  different  kind 
of  automaton  than  the  state  machine 
instantiation. 

The  second  problem  we  encounter  is  that  the 
Goguen-Meseguer  model  allows  us  to  express  a 
much  broader  class  of  security  policies  that 
can  be  expressed  in  the  state  machine 
instantiation.  In  our  reformulation  of  the 
state  machine  instantiation,  we  will  broaden 
the  policies  expressible  to  Include  arbitrary 
non-interference  assertions  as  in  [11. 


users  can  "see"  that  seem  to  be  implicit  in 
the  Goguen-Meseguer  model.  First,  it  seems 
implicit  a  U3er  u  cannot  "see"  the  state 
machine  making  a  transition  from  state  si  to 
state  s2  if  out ( si ,u)=cut ( s2 . u) .  In  other 
words,  a  user  cannot  tell  the  difference 
between  seeing  a  given  output  once  and  seeing 
it  "twice  in  a  row".  If  this  were  not  tho 
case,  then  whenever  any  user  issued  any 
command  to  the  state  machine,  it  would  be, 
seen  by  every  user,  either  as  a  change  in 
output  or  a  "repeat"  of  the  same  output. 

Second,  it  seems  implicit  that  users  cannot 
"see"  time  passing.  In  other  words,  a  user 
cannot  tell  the  difference  between  a  sequence 
of  state  changes  carried  out  over  a  "long" 
time  and  the  same  sequence  of  state  changes 
carried  out  over  a  "short"  time.  Indeed,  the 
Goguen-Meseguer  model  has  no  way  of 
expressing  this  difference. 

We  now  give  a  reformulation  of  our  state 
machine  instantiation  in  terms  of 
Goguen-Meseguer-type  state  machines.  Fix  a 
state  machine  M  consisting  of  a  set  of  users, 
U,  a  set  of  states,  S,  a  set  of  commands,  C, 
a  set  of  outputs,  OUT,  a  function  "out"  from 
S  x  U  into  OUT,  a  function  "do"  from  S  x  U  x 
C  into  S  and  an  initial  state  s.  In 
addition,  fix  a  set  of  commands  A  and  sets  of 
users  G1  and  G2.  We  wish  to  give  an 
instantion  of  the  information  model  to  M 
whose  information  functions  and  information 
flow  restrictions  express  the 

non-interference  assertion  A,  G1  :|  G2. 

The  set  of  possible  worlds  associated  with  M 
is  the  set  of  all  finite  sequences  of 
elements  of  UxC.  Since  Goguen-Meseguer  state 
machines  are  deterministic  and  have  a  unique 
starting  state,  tho  behavior  of  M  during  a 
given  sequence  of  commands  from  users  is 
completely  determined  by  the  sequence  of 
users  and  commands  issued.  We  choose  finite 
sequences  for  the  same  reasons  explained  in 
subsection  5.2 

We  will  now  define  a  few  functions  we  will 
need  later.  Given  a  possible  world 
H=*<  (u(ol  ,cto] ),...,  (u[n]  ,c[  n]  )>  ,  we  can 
define  a  sequence  of  alternating  states  and 
elements  of  Ux6  ST(H)=<s[o],  (u[o),  c[o]), 

s[1),  (u[l3,  ctD),  s[n] ,  (u[  nl ,  c[n]), 

s[n+1]>  where  s[o]=  s  (the  initial  state  of 
M)  and  s[i+1]=  do  (s[i),  u[i],  c[i])  for  i*  , 

. ..,  u.  in  other  words,  ST(H)  is  just  H  with 
the  states  that  M  passes  through  M  the  course 
of  H  "interpolated". 

Given  a  state  s,  we  can  define  a  functions 
V(s )  from  G2  into  OUT  by  V( s ) [g ] =out ( s,g)  for 
all  g  in  G2.  V(s)  is  thus  the  "G2-tuple"  of 
outputs  "seen"  by  the  member  of  G2  in  state 

s . 

We  v;ill  now  complete  the  instantiation.  We 
associate  two  information  functions  with  the 
non-interference  assertion  A,G1  : |  G2  : 

1 .  INPUT  is  the  function  which,  given  a 
possible  world  H,  returns  the 
subsequence  of  H  consisting  of  the 
entries  (u,c)  where  u  is  in  G1  and  c  is 
in  A. 


Before  giving  our  reformulated  instantiation, 
we  will  note  a  few  assumptions  about  what 
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2.  VIEW  is  the  function  which,  given  a 
possible  world  H,  returns  a  sequence 
obtained  as  follows: 

-  Start  with  ST(H).  Delete  from 
ST ( H )  all  entries  (u,c)  such  that 
u  is  not  in  G2.  Call  the  result  X. 
(X  will  be  a  sequence  of  states 
and  user-command  pairs,  not 
necessarily  alternating). 

-  Replace  every  entry  s  of  X  by 
V ( s ) .  Call  the  result  Y.  (Y  will 
be  a  sequence  of  user -command 
pairs  and  functions  from  G2  into 
OUT) . 

Remove  all  consecutive  repetitions 
of  functions  from  G2  into  OUT  from 
Y.  the  result  is  VIEW(H). 

INPUT  simply  extracts  from  H  the  history  of 
inputs  from  users  :Ln  G1  which  are  in  the 
command  set  A.  VIEW  is  slightly  more 
complicated.  Given  H,  it  returns  the  history 
of  commands  from  users  in  G2  and  outputs  to 
users  in  G2,  with  repeated  outputs  ignored. 
These  functions  are  similar  to  the 
hidden-from  and  view  functions  of  the  first 
instantiation. 

Finally,  we  specify  that  it  is  illegal  for 
information  to  flow  from  INPUT  to  VIEW. 

What  is  the  relationship  between  the  two 
definitions  of  security  for  M?  First  of  all, 
a  bit  of  pathology  arises  if  A  is  non-empty 
and  G1  and  G2  overlap.  Since  users  in  G2 
"know"  what  commands  they're  given,  if  a  user 
u  who  is  both  G1  and  G2  issues  a  command  from 
A,  then  the  users  of  G2  can  deduce  something 
about  commands  in  A  issued  Dy  users  in  G1 .  On 
the  other  hand,  it  is  possible  for  A,  G1  :] 
G2  to  hold.  For  example,  suppose  G1=G2={u) 
and  A={c}  where  do  (s,u,c)=x  for  all  states 
S.  Then  A,G1  :|  G2  holds,  i .e.  u  literally 
cannot  interfere  with  himself  by  issuing  c 
because  c  never  causes  any  state  change  and 
so  never  causes  any  change  in  the  output  seen 
by  u.  The  state  machine  instantiation  takes 
into  account  the  fact  that  u  "knows"  more 
than  just  what  he  "sees":  u  also  "knows"  what 
he  "does". 

Thus,  in  the  degenerate  case  where  A  is 
non-empty  and  G1  and  G2  overlap, 
non-interference  does  not  imply  no  flow  from 
INPUT  to  VIEW.  However,  we  do  have 

Proposition  1 :  If  G1  and  G2  are  disjoint  and 
A ,G1  n  G2 ,  then  there  is  no  flow  from  INPUT 
to  VIEW. 

Let  p  be  the  function  which,  given  a  possible 
world  H,  returns  H  with  all  entries  in  GlxA 
deleted.  Proposition  1  will  follow  from  the 
following 

Lemma  1 :  If  G1  is  disjoint  from  G2  and  A,G1 
T|  G2,  then  for  all  possible  worlds  H, 
VIEW ( H) =VIEW  ( p (H) ) . 


Proof  of 

Proposition 

1  from 

Lemma  1 :  We 

need 

to  show 

that  for  any 

A  in 

image! INPUT) 

and 

any  B  in  image! VIEW),  there  exists  a  possible 
world  H  such  that  INPUT(H)»A  and  VIEW(H)=B.  B 


in  image(VIEW)=>  there  exists  HO  such  that 
B=VIEW ( HO ) .  A  in  image! INPUT) A  is  a 
sequence  of  elements  of  GlxA.  Let  H« 
p ( HO ) *  A .  H  is  a  possible  world.  Clearly, 
INPUT (H) =A.  By  the  Lemma,  VIEW(H)= 
VIEW  (  p !  H )  )-~  VIEW(p(p(HO)',;l)  )=  VIEW!  p(p(HO)  )  )  = 
VIEW! p ( HO  )  ) =  VIEW (HO) =B. 

Ill 

Before  giving  the  proof  of  Lemma  1 ,  we  will 
note  a  few  relevant  facts. 

Suppose  H  is  a  possible  world,  u  is  a  user 
and  c  is  a  command.  What  is  VIEW(H,'<  (u  ,c)  >  )? 
To  compute  VIEW(HA< (u,c) > ) ,  we  must  first 
compute  ST(H"<(u#c)>).  If  s  is  the  last 
element  of  ST(H)  (i.e.,  the  state  of  the 
machines  after  "doing"  it),  then  ST(  ir<  (u,c: )  > ) 
is  ST! H) A < (u,c ) ,  do(s,u„c)>.  Next,  we  delete 
all  user-command  pairs  with  user  not  in  G2. 
Let  X  be  the  result  of  performing  the 
operation  on  ST(HA<!u,c)>)  is  : 

XA<(u,c),  do(s,u,c)>  if  u  is  in  G2 

X'‘<do(s,u,c)  >  if  u  is  not  in  G2 

Next,  we  apply  V  to  all  states  in  the 
sequence.  Let  Y  be  the  result  of  performing 
this  operation  on  X;  Then  the  result  of 
performing  the  operation  on  the  sequence 
above  is: 

Y*< (u ,c ) ,  V(do(s,u,c ) ) >  if  u  is  in  G2 
Y*<V(do(s,u,c) ) >  if  u  is  not  in  G2 

Note  that  the  last  entry  of  Y  is  V(s),  The 
last  step  in  constructing  VIEW (H*< (u ,c ) > )  is 
to  eliminate  consecutive  repetitions  of 
values  of  V.  The  result  of  doing  this  to  Y  is 
VIEW(H),  Therefore,  we  have 

Fact  1 :  VIEW ( H~ < ( u  ,c)>)  = 

VIEW! H ) * < ( u,c ) ,  V(do(s,u,c) )>,  if  u  is  in  G2 

VIEW!  ( It)  “ <V (do(  s, u ,c  ) )  > ,  if  u  is  not  in  G2 
and  V(5)  is  not  =  V(do(s,u,c)) 

VIEW ( H ) ,  otherwise. 

As  mentioned  above,  for  any  possible  world  H, 
the  last  element  of  ST(H)  is  the  state  of  M 
after  doing"  H.  It  is  easily  seen  that  the 
last  element  of  View(h)  is  therefore  the 
function  form  G2  to  OUT  which  maps  each  user 
in  G2  to  the  output  "seen"  by  that  user  after 
H  is  "done".  We  denote  the  last  element  of  a 
sequence  Q  by  last(Q).  A  straightforward 
translation  of  the  definition  of 
non-interference  in  [GM]  yields 

Fact  2:  A,G1  : |  G2  if  and  only  if  for  all 
possible  worlds  H,  lafit(VIEW(H) )  «= 
last(VIEW(p(H) ) ) . 

Pro?5  Lemma _ 1_s  The  proof  is  by  induction 

on  the' length  of  H. 

The  base  case  is  H=<>  (the  empty  sequence). 
Then  p ( H )  =  <>  =  H,  so  VIEW(H)  -  VIEW(p(H)). 

We  now  do  the  inductive  step.  Assume 
H=HO“<(u,c)>  and  VIEW ( UO ) =VIEW( p( HO ) ) 
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Casel ;  (u,c  )  is  in  G  xA.  Then 
p(H) =p(HOA < ( u,c ) > ) =p(HO) ,  so  by  Fact  2, 
last(VIEW(H) )»  last(VIEW(p(H) ))= 

last(VIEW(p(HO) ) )=  last ( VIEW ( HO ) ) . 

Since  G1  and  G2  are  disjoint,  u  is  not  G2,  so 
by  Fact  1,  view(H)=VIEW(HOa< (u,c, ) > )- 

VIEW ( HO )A<V(do(s,u,c))>,  if  V(s)  is  not  = 
V(do(s,u,c) ) 

VIEW ( HO ) ,  otherwise. 

But  last (VIEW (HO) )  is  V(s),  so  the  only  way 
that  last(VIEW(H) )  can  =  last( VIEW(HO) )  is  if 
the  second  case  above  holds,  so  VIEW(H)= 
VIEW(HO).  By  the  inductive  hypothesis, 
VIEW(HO)-  VIEW(p(HO) ),  and  p(HO)=  p(H),  so 
VIEW( H ) =  VIEW( p(H ) ) . 

Case  2 ;  (u,c)  is  not  in  G  xA  and  u  is  not  in 
G2.  Then  p(H)  =  p(HOA< (u,c ) > ) =p(HO) A< ( u,c ) > . 
By  Fact  2,  VIEW(H)= 

VIEW ( HO) A  < V (do( s' , U,C ) ) > ,  if  V(s')  is 

not=V(do(s' ,u,c) ) 

VIEW(HO),  otherwise. 

Where  s=last(ST(HO) ) .  Again  by  Fact  2, 
VIEW ( p( H ) ) =VIEW( p( HO ) A  <  ( u ,  c  )  >  )  « 

VIEW ( p ( HO ) ) A < V (do ( s 1 , u , c ) ) > ,  if  V(s')  is  not= 
V (dots' ,u,c) ) 

VIEW ( p (HO ) ) ,  otherwise. 

Where  s ' =last ( ST( p(HO ) ) ) .  By  the  inductive 
hypothesis,  VIEW(HO)=  VlEW(p(HO)).  Therefore, 
V(s)-  last (VIEW ( HO) )=  last(VIEW(p(HO) ) )- 
V(s‘  ). 

Now,  Suppose  V(s)  =  V(dO(s,u,v))  but  V(s')  is 
not=  V(do(s' ,u,c) ).  Then  VIEW (H)-  VIEW(HO) 
and  VIEW ( p( H ) ) ■  VIEW( P(HO) ) A<V(do( s ' ,u,c ) ) > . 
By  Fact  2,  last  <VIEW(H))=  last(VIEW(p(H) ) ). 
But  then 

V(s')-V(s)«  last (VIEW(HO) ) -  last(VIEW(H) )= 
last(VIEW(p(H) ))*  V(do(s' ,u,c) ),  a 

contradiction.  Therefore,  if  V(s>- 
V(do( s,u,c) ) ,  then  V(s')=  V(do(s',u,c)),  and 
so  VIEW(H) =  VIEW ( HO ) =  View(p(HO))- 

VIEW(p(H) ) . 

Next,  suppose  V(s)  is  not-  V(do(s,u,c})  but 
V(s')«  V(do(s‘ ,u,c) ) .  By  an  argument 
completely  analogous  to  that  of  the  previous 
paragraph,  this  lead  to  a  contradiction,  so 
if  V(s)  is  not-  V(do(s,u,c))  then  V(s')  is 
not-  V(do (s 1 , u,c ) ) ;  in  this  case, 

VIEW(H ) -VIEW ( HO) A<V(do(s,u,c)) > 

VIEW(p(H) ) »VIEW( p(HO ) ) A  <V(do ( s 1 ,u,c) )> 

VIEW (HO) «  VIEW ( p(HO) )  by  the  inductive 
hypothesis,  and  by  Fact  2, 

V(do(s,u,c ) ) -last ( VIEW( H) ) «  last(VIEW(p(H) ) ) = 
V(do(e' ,U,C) ),  so  VIEW ( H) -  VIEW ( p( H ) ) . 

Case  3:  (u,c)  is  not  in  G  xA  and  u  is  in  G2. 
■then  p(H)  =  p(HO)A<(u,c)>.  By  Fact  1, 


VIEW(H)=VIEW(HO)A<(u,c),  V(do(s,U,c) ) > 

VIEW( p(H ) ) =VIEW( p(HO) )A<(u,c),  V(do(S ' ,U,c) ) > 

VIEW ( HO) =  VIEW(p(HO) )  by  the  inductive 
hypothesis,  and  the  last  elements  of  the 
above  sequences  are-  by  Fact  2,  so  again, 
VIEW ( H ) =  VIEW(p(H) ) 

/// 

The  converse  of  Proposition!  fails  in  a 
non-pathological  case  however. 

Proposition  2:  No  flow  from  INPUT  to  VIEW 
does  not  imply  A,G  :|  G  . 

Proof:  Consider  the  following  state  machine: 


U={u1 ,u2,u3) 

S={0,1 }x{0 ,1 } 

C={flipl ,fliP2) 

OUT-  {0.,  1  ) 

out ( ( b! ,b2) ,u)= 

bl  if  u-ul 
0  otherwise 

do  ( (bl ,b2 ) ,u,c) = 


(bl 

,b2) 

if 

u-ul 

(bl 

,b2) 

if 

u«u2 

and 

b2-0 

(bl 

,b2) 

if 

u-us 

and 

b2=1  and 

c-flip2 

(1- 

bl ,b2) 

if 

u=u2 

and 

b2-1  and 

c-flipl 

(1- 

bl ,b2) 

if 

u-u3 

and 

c=f lipl 

(bl 

,1 -b2) 

if 

u-u3 

and 

c-f lip2 

so- ( 1  ,1  ) 

Briefly,  the  state  consists  of  2  flags.  ul 
can  see  the  first  flag,  while  u2  and  u3  can't 
see  anything .  There  are  2  commands ,  one  to 
flip  the  first  flag  and  one  to  flip  the 
second  flag.  Commands  from  ul  are  always 
ignored.  Commands  from  u2  to  flip  the  second 
flag  are  always  ignored,  whereas  commands 
form  u2  to  flip  the  first  flag  are  carried 
out  if  the  second  flag  is  1 ,  and  are  ignored 
otherwise.  Commands  from  u3  to  flip  either 
flag  are  always  carried  out. 

Let  A-(flipl),  G1={u2)  and  G2-(u1). 

Claim  1 :  A,G1  : |  G2  does  not  hold.  Consider 
tKe  possible  world  H=< (u2,flip1 ) > .  After  H, 
ul  is  "seeing"  a  p(H)*<>/  After  p(H),  ul  is 
"seeing"  a  1.  By  definition  of 
non-interference,  the  above  assertion  does 
not  hold. 

Claim  2:  There  is  no  flow  from  INPUT  to  VIEW. 
Rather  than  give  a  completely  rigorous  proof, 
we  will  simply  indicate  why  claim  2  is  true. 
We  wish  to  show  that  ul  cannot  possibly 
deduce  anything  about  u2 ' s  inputs  by 
observing  his  own  inputs  and  his  outputs. 
The  reason  this  is  true  is  because  anything 
that  ul  sees  could  be  the  result  of  u3 
issuing  fiip2,  u3  issuing  flipl  a  certain 
number  of  times,  and  u2  issuing  any  sequence 
of  commands.  In  other  words,  no  matter  how 
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many  times  ul  sees  the  first  flag  flip,  it 
could  always  be  the  result  of  u3  issuing  flip 
1 ,  and  if  u3  in  addition  issues  flip  2 
immediately,  all  of  u2's  inputs  are  “masked 
out". 

The  essential  difference  in  this  example 
between  the  Goguer.-Meseguer  model  and  the 
information  model  instantiation,  is  that 
Goguen-Meseguer  requires  that  there  be  no 
change  in  what  ul  sees  when  u2 1 s  inputs  are 
deleted  while  holding  u3 1 s  inputs  fixed.  The 
Goguen-Meseguer  model  requires  u3's  inputs  to 
be  held  fixed  even  though  ul  has  no  way  of 
knowing  what  they  are. 

In  conclusion,  the  state  machine 
instantiation  of  the  information  model  given 
above  seems  (if  certain  pathological 
situations  are  ruled  out)  to  be  a 
generalization  of  the  Goguen-Meseguer  model. 
It  is  a  proper  generalization  in  the  sense 
that  it  is  implied  by  Goguen-Meseguer  but 
does  not  always  imply  Goguen-Meseguer. 
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ABSTRACT. 

Wo  give  a  rigorous  mathematical  definition  for  the  concept  of  a 
variable  being  read  by  a  process  and  give  evidence  that  this 
definition  captures  the  correct  Intuitive  notion  with  applications  to 
security  specification  and  verification.  We  examine  the 
expressibility  of  "read"  in  various  temporal  logics,  getting  some 
positive  and  some  negative  results.  We  dell.  .a  what  it  means  for 
a  host  machine  to  Implement  a  target  machine  in  such  a  way  that 
a  given  variable  is  not  read.  We  show  that  'read*  is  theoretically 
decidable  and  give  some  proof  rules.  In  a  later  paper  we  Intend 
to  give  axioms  and  proof  rules  for  such  ‘protected 
implementation’  proofs  In  the  context  of  the  State  Delta 
Verification  System  being  developed  at  The  Aerospace 
Corporation  (see1). 

This  formulation  Is  rather  new,  and  we  are  etiU  exploring  its 
technical  properties  and  applications. 


’Thle  work  wu  tupported  In  part  by  tha  Aaroapaoa  Sponsored  Rxoarch 
program. 


INTRODUCTION 

In  dealing  with  computer  security,  a  major  consideration  Is 
protecting  certain  registers  from  being  read  from  or  written  Into 
by  unauthorized  processors  or  users.  It  Is  fairly  trivial  to  deline 
tha  semantics  of  write:  if  the  value  of  the  register  changes,  it 
was  written  Into.  (This  is  Ignoring  the  rare  occasion  when  writing 
a  value  which  is  the  same  as  tha  current  value  may  be  of 
Interest.) 

However,  detecting  when  a  register's  yalue  has  been  read  Is  a 
much  more  delicate  matter.  For  a  register  x  to  be  read,  we  do  not 
require  that  the  reader  actually  ‘look  at"  or  access  the  x,  nor  that 
the  reader  learn  the  value  of  the  contents  ol  x  in  any  way.  We 
view  ‘reading’  as  a  special  case  of  the  general  problem  of 
Information  flow.  Intuilivefy,  we  will  consider  a  register  x  to  have 
been  read  by  (or  during)  process  P,  If  some  non-public  or 
protected  Information  about  its  contents  becomes  known  during 
an  execution  of  P,  l.e.,  if  the  behavior  of  P  Is  dependent  on  the 
value  of  x  in  some  specifiable  or  observable  way.  This  means 
that  the  concept  ot  ‘non-public'  must  be  made  explicit  in  every 
specific  case  of  read. 

A  superficial  approach  to  tha  semantics  ot  read  yields  the 
following  examples,  if  the  right  hand  side  of  an  assignment 
statement  consists  of  the  program  variable  x  by  Itself,  then  x  is 
read.  If  the  expression  x  -  x  (subtraction)  Is  on  the  right  hand 
side,  It  is  no!  completely  clear  whether  we  want  to  consider  x  to 
have  been  read  or  not.  if  x  appears  In  a  condition  for  a  branch, 
where  the  outcome  of  branch  depends  on  the  value  of  x,  we 
probably  do  want  to  oonsider  that  x  has  been  read,  even  H  we 
don't  need  to  know  its  explicit  value. 
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These  examples  all  rely  on  the  presence  of  some  syntax  fcr 
their  formulation.  The  situation  is  clearly  different  In  the  case  of 
security  verification.  We  shall  consider  a  prototypical  relation 
between  an  adversary,  A,  and  a  process,  P.  The  adversary  tries 
to  learn  something  new  about  x  by  examining  the  behavior  of  the 
process  and  by  using  the  public  knowledge,  K,  available  about  x. 
A,  in  general,  does  not  have  complete  knowledge  about  the 
syntax  of  P;  A  may  observe  P  In  operation  or  may  wait  until  P 
has  tennlnated  (If  ever),  and  then  analyze  the  results  to  deduce 
the  new  information  about  x.  in  this  case,  disclosure  of  new 
knowledge  about  x  means  that  some  behavior  of  x  which  is  a 
priori  possible  In  the  context  ol  of  K,  Is  discovered  to  be 
impossible  in  light  of  P. 

The  link  between  the  syntactic  and  the  general  formulation 
can  be  seen,  (or  example,  In  the  simple  assignment  statement 
above:  a  possible  value  ot  x  (actually,  all  but  one  possible  value 
of  x)  Is  eliminated  by  examining  the  value  of  the  left  hand  side. 
Likewise  In  the  branch  example,  the  negation  of  the  realized 
branch  predicate  is  discovered  to  be  Impossible  at  that  point  in 
time  In  that  computation  (the  realized  branch  predicate  Is 
discovered  to  be  true). 

Our  approach  elevates  this  ’public  knowledge*  to  a  position  ol 
prominence  In  the  definition.  K  plays  a  dual  role  In  the  sense 
that  It  can  be  used  by  the  adversary  to  deduce  Information  about 
x  based  on  observation  of  P,  but  K  also  Is  the  criterion  for 
deciding  it  that  information  about  x  is  new.  For  example,  If  the 
public  knowledge  about  x  is  weak  (e.g.,  K  -  TRUE),  and  x  is  not 
an  explicit  variable  of  P,  then  x  is  not  read  by  P  because  there  is 
no  way  to  connect  x  with  the  behavior  of  P.  Aiso,  if  K  is  too 
strong  (e.g.,  K  •  FALSE),  then  x  is  not  read  by  P,  because  P 


could  not  possibly  Increase  our  knowledge  about  x.  Actually,  x 
can  alternate  between  being  read  and  not  being  read  with 
respect  to  K  as  K  Increases  in  strength.  On  the  other  hand,  for 
any  non-trivlal  process  P  and  register  x,  there  is  some  public 
knowledge  such  that  with  respect  to  it,  P  reads  x:  simply  take  K 
to  be  x  -  v  for  some  variable,  v,  of  P. 

We  assume  a  strict  distinction  on  the  one  hand  between  the 
variables  gf  a  process,  Var(P),  which  P  knows  everything  about 
at  all  points  of  all  computations  and  by  definition  reads, 
analogous  to  real  locations  in  a  machine  for  P,  and  on  the  other 
hand,  external  variables  which  P  may  or  may  not  read, 
depending  on  K. 

We  take  the  view  that  the  specification  of  a  process  Is  a  way 
of  restricting  the  possible  computations  that  the  user  can 
perform,  rather  than  permitting  them.  We  are  Interestad  In 
protecting  against  the  Inadvertent  read,  riot  finding  which 
registers  are  always  read.  Thus,  the  fewer  computations  the 
user  can  perform  (the  (ewer  models  the  process  has),  the  less 
chance  of  x  being  read. 

There  are  four  separable  concerns  which  need  formalization: 
the  new  information  learned  about  x  by  P  Is  ’Information',  It  Is 
"new",  it  is  "about*  x,  and  it  Is  learned  "by"  P.  As  mentioned 
above,  the  ‘newness’  will  bo  measured  In  relation  to  K; 
"information"  is  taken  to  be  a  set  of  possible  computations.  The 
‘about  x"  and  "by  P"  are  handled  by  looking  at  the  restriction  of  a 
model  ot  K  to  x,  and  combining  this  with  a  computation  of  P. 

To  formalize  the  above  discussion  In  precise  mathematics,  we 
utilize  tho  concepts  of  model  theory1,  In  the  sense  of2.  We 
assume  only  very  basic  acquaintance  with  logical  concepts  and 


model  theory.  We  start  out  with  a  model  (computation)  of  K,  and 
we  restrict  It  to  x  (Ignore  the  other  variables).  This  represents  a 
possible  behavior  of  (or  Information  about)  x  consistent  with 
K.  Now  take  a  model  (computation)  of  P  and  see  if  we  can 
superimpose  the  above  restricted  model  onto  this  model  of  P  In  a 
way  which  Is  consistent  with  K,  i.e,  such  that  the  combination  Is  a 
model  of  K.  if  we  cannot,  then  we  have  learned  that  this  behavior 
of  x  Is  ruled  out  by  this  particular  computation  of  P,  and  x  Is  read. 

It  could  be  that  the  forbidden  behavior  (the  information)  Is 
specifiable  by  a  sentence  In  a  given  language.  This  means  that 
there  is  a  sentence,  F,  such  that  the  above  holds  tor  all  models 
of  K  a  -.F.  (in  other  cases,  it  may  be  that  a  particular  model  or 
set  of  models  is  ruled  out,  but  this  model  or  set  of  models  is  not 
specifiable  In  the  language.)  If  M  does  not  read  x  with  respect  to 
K,  then  the  adversary  cannot  deduce  anything  about  x  that  does 
not  already  follow  from  K.  See  Lemma  3. 

We  examine  the  possibility  of  expressing  the  necessary 
semantics  within  various  temporal  logics  and  come  to  the 
conclusion  that  this  is  Impossible  In  some  cases. 

There  are  several  possible  variations  of  the  formalization 
which  seem  reasonable.  An  Important  task  is  to  examine 
examples  and  results  about  their  interdependencies  in  order  to 
determine  which  ones  correctly  represent  our  Intuition. 

See3,4,  and5  tor  discussions  of  similar  problems. 

IXAMPLES 

Example  1:  Consider  a  system  with  two  processes  sharing  a 
common  CPU:  P,,  which  uses  variable  y,  and  P2,  which  uses 
variable  x.  Each  has  exclusive  use  of  the  CPU  for  five  clock 


cycles.  Every  five  clock  cycles  the  CPU  will  swap  the  other 
process  In  If  ft  so  requests,  and  the  first  process  Is  then  swapped 
out.  Let  K  be  the  description  of  this  system.  It  Is  tore  that  x  Is 
read  by  P,  with  respect  to  K,  since  when  P,  Is  running,  It  knows 
that  x  cannot  be  changing. 

However,  the  only  Information  that  P,  gains  about  x  is  that  x  is 
not  active  when  P1  Is  running.  Assume  now  that  the  system 
contains  another  variable,  "status',  that  holds  the  name  of  the 
active  process  tor  each  point  In  the  timeline,  and  let  K'  be  the 
description  of  the  new  system  along  with  a  particular  choice  of 
values  for  status.  Then  Pt  does  not  read  x  with  respect  to  K'. 

For  a  more  detailed  analysis  ot  this  example  see  Example  4. 

Example  2:  II K  Is  x  »  0  or  K  Is  TRUE,  then  no  process  reads 
x  with  respect  to  K.  K  either  contains  all  the  possible  Information 
about  x,  or  does  not  give  any  connection  between  x  and  other 
variables.  ltKlsv«C->x-0.  then  any  computation  satisfying 
3t(v(t)-0)  reads  x  with  respect  to  K.  Notice  that  this  Is  an 
example  of  K,  ->  K2  K3  and  a  computation  that  reads  x  with 
respect  to  the  middle  K  but  not  with  respect  to  the  two  outer 
ones. 

If  K  is  ’0<x<5  a  0<v<5  a  x-v‘  or  ‘0<x<5  a  0<v<5  v  x-v»6’  then 
x  is  read  by  every  process  with  respect  to  K.  II K  Is  lust  *0<x<5  a 
0<v<5\  then  x  Is  not  read  by  any  process  with  respect  to  K.  This 
Is  an  example  of  K,  • » K2  -♦  K3  such  that  x  is  read  with  respect 
to  the  outer  ones,  but  not  read  with  respect  to  the  middle  one. 

Example  3:  It  K  -  ’u  +  x  ■  v’,  and  u  and  x  are  not  variables  of 
the  process  P,  then  P  does  not  read  x  with  respect  to  K. 
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THE  FORMAL  DEFINITION  OF  READ 

We  consider  a  computation  (or  a  process  to  be  specified  when 
we  Know  the  values  ot  ail  process  variables  at  every  point  in 
time.  A  process  thus  determines  a  set  of  computations,  its  set  of 
possible  computations.  Formally,  this  becomes  a  class  of 
models  based  on  an  arbitrary  linear  order  <T,  <>  representing  the 
timeline  of  the  computation.  At  each  point  t  of  T  a  state  Is 
specified  by  defining  the  values  of  the  functions  v(t),  where  v  can 
be  thought  of  as  a  program  variable  and  v(t)  Its  contents  at  t. 

For  a  given  process,  T  may  change  from  computation  to 

computation,  but  the  domain  of  values  Is  fixed. 

Definition  1 :  A  computational  model  for  program 
variables  V  over  the  linear  order  O',  <)  Is  a  structure  of 

the  form  M-(TuD;  <,v . R,  ...)„,  vwhere  v,  ...  are 

function  symbols  to  bo  Interpreted  as  functions  from  T 
to  D  (the  "domain  of  data")  and  R,...  are  relations  (and 
functions)  on  D. 

Let  L(M)  >{<|uVu  {R, ...)  be  the  language  of  M,  Var(M)  -  V 
be  the  set  of  variables  of  M. 

A  process  (or  program  or  theory)  a  is  a  class  of  computational 
models  with  V,  D,  and  R, ...  fixed.  We  call  (D;  R, ...)  the  domain 
of  a.  In  that  case  we  write  M)-o  H  M  e  a  and  define  L(a)  -  L(M) 
and  Var(c)  -  Var(M).  If  ^  is  a  sentence  in  the  appropriate 
language,  then  MW  has  the  standard  meaning  (see2). 

So  for  example,  by  using  time  as  an  explicit  variable  we  can 
say 

MK3l16T)(vtl4eT)(t1  - 12  v  t,  >  t2),  or 

MKMTKVfciTKfa  * «i  -*\,v%  -  v(t,)) 

(two  versions  of  terminating  computation),  or  M)»vteT(v(t)>u{t}), 
etc. 

In  tlte  following,  when  we  say  "model"  we  mean 


"computational  model". 

Now  we  want  to  define  the  formal  counterpart  of  the  intuition 
ot  comparing  a  possible  behavior  of  x  to  actual  behaviors  of  x 
allowed  by  M.  Remember,  our  definition  will  say  that  x  Is  read  by 
M  with  respect  to  K  If  there  Is  a  behavior  of  x  that  is  possible 
according  to  K,  but  which  Is  not  allowed  by  M. 

Informally  still,  given  a  model  M  with  x  as  a  variable,  the 
behavior  of  x  In  M  is  simply  the  mode!  obtained  by  Ignoring  all 
the  other  program  variables.  Formally,  this  Is  the  restriction  ol  M 
to  x. 

Definition  2:  It  M  Is  the  above  model  (Var(M  -  V) 
and  U  Is  any  set  of  program  variables  (typically,  but  not 
necessarily,  U  c  V)  we  define  the  restriction  of  M  to  U 

by  MfU  -  <T  u  D;  <,  v .  R,  ...)„unV  M  ls  an 

expansion  of  MfU. 

in  compliance  with  the  standard  terminology,  we  use 
"expansion"  for  a  model  obtained  by  enriching  the  language,  and 
"extension"  for  a  model  obtained  by  enlarging  the  underlying  set. 

A  behavior  ol  x  which  Is  possible  according  to  K  Is  lust  M/fx) 
for  M,h  K.  The  behavior  of  x  Is  allowed  by  a  model  M II  when  we 
glue  this  behavior  to  M  we  get  a  model  ot  K. 

If  M,  -  (T  u  D;  <,  V .  R.  ...)wV  and  - 

(TuD;<,  v . R,  are  models  over  the  same  timeline 

and  with  the  same  domain,  M,rv1nV?  s  M/VtnV2,  then  u 
Mj-(TuD;  <,  v, ....  R,  .••>**  v,uV,' 

Here  is  the  main  definition: 

Definition  3:  Let  M  be  a  model  over  T  as  above, 

K(  v,  x)  a  sentence  In  L(M)  u  (x).  K  reads  x  with 
respect  to  K  if  M  has  an  expansion  to  a  model  of  K  but 
there  is  M,  j»K  over  T  such  that  (M,f{x})uM  |4K. 

If  K  -  K(  v,  u,  x)  contains  additional  variables  e  L(M)  besides 
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x,  then  the  definition  becomes: 

Definition  4:  M  (over  T)  reads  x  with  respect  to 
K(  v,  u,  x)  if  M  has  an  expansion  to  a  model  of  K,  but 
there  is  a  model  M,  over  T  such  that  {x}  vj  M 
has  no  expansion  to  a  model  of  K. 

The  intuitive  reason  that  we  Insist  that  M  be  consistent  with  K 
Is  that  otherwise,  the  "adversary"  would  not  be  able  to  observe  M 
at  all:  K  and  M  could  not  coexist.  The  "new  information"  about  x 
is  that  m/M  is  not  allowed.  Thus,  the  possibilities  for  x 
satisfying  K  are  restricted. 

Definition  S:  x  Is  read  by  a  with  respect  to  K  if  there 
exists  M)>o  such  that  x  is  read  by  M  with  respect  to  K. 

Example  4:  Now  let  us  return  to  Example  1.  Let  M  be  any 
model  of  P,;  remember,  M  does  not  mention  x.  M  is  obviously 
consistent  with  K,  i.e„  It  has  an  expansion  to  a  model  of  K.  For 
example,  x  can  be  defined  to  be  always  idle.  If  y  Is  not  idle  in  M, 
then  M  reads  x  with  respect  to  K.  since  there  is  a  model  M,  of  K 
which  has  x  changing  exactly  at  the  time  that  M  has  y  changing. 

Now  consider  the  case  with  the  added  status  word.  Let  M0  be 
a  particular  graph  of  the  status  word  and  let  K'  -  K  n 
{M:  Nf  (status)  -  M0).  Then  x  is  not  read  by  any  M  with  respect  to 
K',  since  the  non-active/potentially  active  behavior  of  x  Is 
determined  by  status.  -| 

Tnc  PADDED  VERSION  OF  READ 

Now  we  shall  give  an  alternate  definition  which  relaxes  the 
condition  that  the  behavior  of  x  which  Is  excluded  by  M  must  be 
realized  over  a  timeline  identical  to  M's.  We  shall  be  looking  at 
models  of  K  whose  timelines  can  be  superimposed  on  the 
timeline  of  M  in  a  consistent  manner.  This  is  the  concept  of 
"padding". 


We  shall  not  give  a  formal  definition  of  "padding",  but  it  is 
sufficient  to  think  of  a  padded  version  of  M  as  a  model  over  a 
larger  timeline  In  which  some  states  of  M  are  spread  out  (in 
either  direction). 

Definition  6:  x  is  strongly  read  by  M  over  T  with 
respect  to  K  H  there  is  a  padding  of  M  to  a  model  of 
K(  v,  x),  but  there  Is  M,j-K  over  T,  a  T  and  M2,  a 
padding  of  M  to  T,,  such  that  M/M  u  M2  |*{K). 

The  intuition  is  that  wo  have  some  property  ot  x  consistent 
with  K:  this  Is  embodied  in  our  choice  of  Mv  However,  by 
"running"  o  under  certain  circumstances  (over  the  “iypad"  of  M) 
we  eventually  come  to  the  conclusion  that  this  property  of  x 

consistent  with  K  cannot  be  true. 

Definition  7:  x  Is  strongly  read  by  o  with  respect  to 
K  if  there  is  Mj*  a  such  that  x  is  strongly  read  by  M 
with  respect  to  K. 

Definition  8:  A  language  L  Is  paddable  if  padding 
preserves  L-equIvalence  between  L-models. 

Theorem  1 :  In  the  case  of  paddable  language,  If  x 
is  strongly  read  by  a  with  respect  to  K,  thon  x  is  read 
by  a  with  respect  to  K. 


For  example, 

Theorem  2:  The  languago  of  "weak  until"  (WU)  ic 
paddable,  where 

Definition  9:  WU  Is  the  set  of  sentences  formed 
from  first  order  logic  (not  containing  <)  and  dosed 
under  conjunction,  disjunction,  negation,  and  U*: 

(M,  g  (=  PU*Q  iff 

(Bi2  2:  i0)  (Q(i2)  a  (Vt,)(i0si,st2  ->  P(i,))). 
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THE  CASE  OF  SPECIFIABLE  INFORMATION 

So  far,  we  have  studied  "read'  in  a  General  framework,  where 
the  information  learned  about  x  took  the  form  of  a  given  model  or 
behavior  which  was  excluded  from  the  set  of  possible  behaviors. 
Now  we  examine  the  situation  In  which  the  Information  read 
about  x  is  expressible  in  a  given  language. 

The  reason  for  this  new  definition  is  that  the  previous  definition 
was  in  a  sense  too  strong,  l.e.,  x  could  be  read,  but  the  behavior 
which  was  excluded  was  not  specifiable,  and  thus  the 
information  gained  could  not  be  "used". 

Definition  10:  M  (over  T)  discovers  F(  v,  x)  with 
respect  to  K  if 

1 .  there  is  an  expansion  of  M  to  a  model  of  K, 

2.  there  is  K  a  F  (F  does  not  follow  from 

K). 

3.  if  M,  h  K  a  -,F.  then  {x]uM|.  -iK. 

For  example,  if  K  is  v(t)-0  ->  x(t)«0,  then  M  satisfying  v(t)»0 
discovers  x(t)«0. 

Discovery  satisfies  the  following  Intuitive  properties; 

Lemma  3: 

1 .  If  M  discovers  F  with  respect  to  K,  then  M 
does  not  discover  -,F  with  respect  to  K. 

2.  If  M  discovers  F,  with  respect  to  K,  then  M 
discovers  F,  a  F2  with  respect  to  K. 

3.  If  M  discovers  F(  v,  x)  with  respect  to  K,  then 
M  reads  x  with  respect  to  K. 

Actually  this  definition  works  just  as  well  for  F  an  arbitrary  set 
of  models. 


READING  DURING  AN  INTERVAL 
We  can  further  refine  the  main  definition  to  talk  about  when  the 
reading  takes  place. 

Definition  11:  M  (over  T)  reads  x  with  respect  to  K 
during  the  Interval  I  c  T  If  M  has  an  expansion  to  a 
model  of  K,  but  there  is  M,|-  K  over  T  such  that  M,[T 
cannot  be  extended  to  M2|-  K  over  T  such  that 
Mjf  (x)  u  M  |-  K. 

Soic?  Intuitively  desirable  properties  hold: 

Lemma  4: 

1 .  "M  (over  T)  reads  x  with  respect  to  K  during 
the  Interval  T"  (M's  whole  timeline)  reduces  to 
the  original  definition  of  M  (strongly)  reads  x 
with  respect  to  K. 

2.  “M  (over  T)  reads  x  with  respect  to  K  during 
the  interval  1“  Is  not  the  same  as  "Nfl  reads  x 
with  respect  to  K.“ 

3.  If  M  does  not  read  x  with  respect  to  K  during 
the  interval  I,  then  the  same  holds  true  for 
every  sublntervai  of  I. 

Unfortunately, 

Example  5:  Read  protection  during  intervals  does  not  finitely 
compose.  That  Is,  there  is  M  ove.  T,  t,  s  t2  <;  t3  e  T,  K,  such  that 
M  does  not  read  x  with  respect  to  K  during  [t1,  t2],  M  does  not 
read  x  with  respect  to  K  during  [t2,  tj,  but  M  does  read  x  with 
respect  to  K  during  (t1,  tj. 

Read  protection  during  Intervals  does  not  compose  in  the  limit, 
either.  That  is,  there  is  M  over  T  *  u1<(o[t0,  t,]  such  that  x  Is  not 
read  with  respect  to  K  during  [tQ,  tj]  for  ail  i,  but  M  docs  road  x 
with  respect  to  K  during  T.  ^ 


READ  AND  RELEVANCY 

Definition  12:  v  reads  x  with  respect  to 
K(  v,  u,  x)  H  there  is  a  model  M  such  that  MT{  v)  and 
R^(x)  have  expansions  to  models  of  K,  but 
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mT(v)u  Mf(x)  does  not. 

Note  that  if  M  reads  x  with  respect  to  K,  v  e  UM),  then  v  reads 
x  with  respect  to  K. 

Definition  13:  v  reads  x  with  respect  to  K  and  y  if 
there  is  M  such  that  MTxuy  and  Mfv uy  have 
expansions  to  models  of  K,  but  Mf  vu  xu  y  does  not. 

Note  that  v  reads  x  with  re  lect  to  K  and  0  iff  v  reads  x 
with  respect  to  K. 

Notation  lK(  x,  u,  v)  holds  if  v  does  not  read  x  with  respect 
to  K  and  u.  IK  Is  to  be  compared  to  the  'irrelevancy  relation' 
from  Pearl  and  Paz6.  There  the  common  knowledge  K  is  not 
made  explicit. 

Lemma  5: 

1.  IK(  x,  ij.  v)  iff  lK(  v,  u,  x) 

2.  IK(  x,  u,  v  u  w)  ->  IK(  x,  u,  v)  a 

IK(x.  U,  w). 

S. IK(x,  Ci.  vu  w)-»lK(x,  uuw.  v). 

4.  IK(x,  u,  w)  a  IK(x,  u  uw,  v)  -» 

IK(x,  u>  vuw), 

These  are  conditions  (11. a),  (ll.b),  (ll.d),  and  (25)  of  (6). 

Condition  (1 1  .c)  from8  is  not  true:  i.e., 


IK(  x.  u  u  v,  w)  a  IK(  x,  uuw.  v)  -Mk(  x,  u,  v  u  w). 


EXPRESSIBfLITY  OF  READ 
Definition  14:  A  logic  L  expresses  read  If  for  all 
K(  v,  u,  x)  e  L,  there  IsoeL  such  that  tut  does  not 
read  x  with  respect  to  K  if  and  only  If  M  H  a. 

Note  that  it  in  order  to  show  that  L  does  not  express  read,  it  Is 
suificiern  to  find  Mt,  M2  satisfying  the  same  L-ssntenuos  such 


that  one  reads  and  the  other  does  not. 


This  method  can  be  used  to  prove: 

Theorem  6:  WU  doer  -ot  express  read. 

For  similar  results,  see7.  The  proof  we  have  involves  non- 
standaid  timelines  (i.e.,  not  isomorphic  to  the  natural  numbers) 
and  infinite  domain  set.  It  Is  not  known  tf  all  WU-equlvalent 
models  over  timeline  u  with  finite  domain  set  are  also  read- 
equivalent. 

One  positive  result  though: 

Lemma  7:  If  K  is  static  (over  one-point  timelines)  or 
time  universal,  then  read  with  respect  to  K  is 
expressible. 


READ  AS  A  GENERALIZED  QUANTIFIER 

In  this  section  we  express  “road"  as  a  generalized  quantifier  in 
the  sense  of8.  This  gives  us  a  syntax  to  uso  In  reasoning  about 
read  statements. 

We  introduce  the  quantifier  where  M  )-  9txK  will  mean  that 
M  reads  x  with  respect  to  K  (when  K  does  not  contain  any 
occurrences  of  9tx.) 

Example  6: 

1.  Trie  example  of  K  from  Example  1  generalizes  to  F 
3y-iG(y)  a  G(v)  ->  9tx(G(v)  -4  -iG(x)))  (which  Is  a 
special  case  of  4  below.) 

2.  The  example  of  K  being  '0<x<5  a  0<v<5  a  x-v’ 
from  Example  2  generalizes  to  (•  3*2yG(y)  a  G(v) 

->  9tx(G(v)  A  X  m  v). 

3.  The  example  of  '0<x<5  a  0<v<5  v  x-v-6' 
generalizes  to  H  3yG(y)  a  -tG(v)  ->  9tx(G(v)  v  x  - 

v). 

4.  The  example  of  V-0  -» x-0'  generalizes  to  )•  G,(v) 


190 


a  3yG2(y)  a  3y-,G2(y)  -> 9tx(G,(v)  ->  G2(x)).  ^ 

Theorem  8:  The  following  are  valid  statements 
(true  in  every  L-model,  where  x  e  L): 

1.  If  x  does  not  occur  in  G,  and  v  does  not  occur 
in  G2,  then  -VKx(G.(v)  a  G2(x)). 

2.  If  x  does  not  occur  In  G,,  then  9?X(G,  a  G,)  -> 

G1  a  9txG2. 

3.  «X(G,  a  G2)  -» 2txG,  v  9t„G2. 

4.  dyG^y)  A  3y— iG,(y)  a  3yG2(y)  a  3y--.G2(y)  -> 
®x(®t(v) 

5.  VyG(v,  y)  ->  -,9txG(v,  x).  (This  implies  G,(v) 
-»-,5tx(G,(v)  vG2)). 

6.  Vy-iG(v,  y)  -»  -,9txG(v,  x). 

7.  G,(v)  a  3yG2(y)  a  3y->G2(y)  -> 

Wx(Q,(v)  G2(x)), 

We  do  not  know  I-jw  to  expand  the  above  set  to  get  a 
complete  axlomatlzation  of  read. 

Note  that  the  following  is  not  valid: 

F  a  9txK  ->  9tx(K  a  F),  for  x  not  occurring  In  F. 

This  is  the  converse  of  2  above. 

Example  7:  There  a.e  Gj  such  that  tha  following  are 
satisfiable: 

1. 9txG,  a  9tx(— iG,) 

2. 9txG2  A  — i9tx(— iG2) 

3.  —i9txGg  a  — iOt  x( — iG?) 

Take  G,  =  x>v,  G2  *  - i(P(x)  a  G(v) ) ,  and  Q2  ■*  TRUE  (or 
FALSE). 

DECIDABILITY  OF  READ 

In  this  section  we  show  that  ’read*  Is  decidable.  More 
precisely,  we  show  that  for  a  fixed  (finite)  domain  D,  the  theory 
consisting  of  the  set  of  sentences  in  the  logic  with  9tx  which  are 
true  in  all  computational  models  over  D  with  countable  timelines 


Is  decidable.  The  result  follows  by  Interpreting  9tx  In  the  second 
order  monadic  theory  of  countable  chains,  shown  to  be 
decidable  in9.  Second  order  monadic  logic  allows  quantification 
over  subsets,  but  not  arbitrary  relations  or  functions.  This  result 
Is,  of  course,  only  of  theoretical  Interest  without  practical 
application,  since  the  size  of  the  domain  Is  typically  very  large. 

Let  D  -  (d1 . dr)  be  a  given  finite  domain.  Let  9tx  be  the 

read  quantifier  for  countable  computational  models  over  D.  That 
is,  M  h  9txK  if  M  is  a  computational  model  over  0  with  countable 
timeline  T,  there  is  an  expansion  of  M  satisfying  K,  and  there  is 
M,  |-  K  sucti  that  Mj’s  timeline  Is  T  and  M  u  M/jx)  )A  K.  Let 
Th(9tx)  be  the  set  of  sentences  in  the  above  language  which  are 
satisfied  In  every  computational  model  over  D  with  countable 
timeline. 

Theorem  9:  Th(9lx)  Is  decidable. 

Proof:  In  order  to  interpre.  Th(9t)x)  in  the  monadic  second- 
order  theory  of  linear  order,  first  we  Interpret  2tx  In  the  logic 
allowing  quantification  over  functions  from  T  to  D: 

M  9txK  iff 

M  (•  (3fx:T  -*  D)  K(v“,  fx)  a  (3fv',  </,  ...  :T  -»D)[K(fv',  fx*)  a 
— ,K(vm,  f/)]. 

Now  we  write  3fx  as  a  finite  sequence  of  set  quantifiers  over  T : 

fdfx:T-»D)(Mfx)  <-»  (3D,, Dn  c  T)  (the  D|  are  paiiwise  disjoint 
a  ^(D,,  ....  Dn)),  where  replaces  ...fx(t)...  with 
A(D,(t)  -»  ...d|...).  H 
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PRACTICAL  FORMULATION  OF  READ  PROTECTION 

The  real-world  situation  that  served  as  the  motivation  lor  the 
development  of  this  concept  of  read,  and  that  will  serve  as  the 
final  judge  of  Its  viability,  is  the  following:  given  a  host  machine 
(code),  H,  and  a  target  machine  (specif icatton),  T,  H  implements 
T  In  such  a  way  that  variable  x  Is  not  read.  See’  or10. 

In  order  to  make  this  statement  precisely  fit  the  mold  of  the 
formal  definition  of  read  presented  In  this  paper,  we  need  to 
specify  what  formulas  (programs)  will  play  the  roles  of  o  and  K, 
the  relevant  process  and  public  knowledge. 

Proposal: 

Definition  Is  H  implements  T  in  such  a  way  that  x 
is  not  read"  if 

1.  H  Implements  T 

2.  T  does  not  read  x  with  respect  to  H. 

So  wq  are  suggesting  that  a  -  T  and  K  -  H.  x  can  bo  (and 
usually  is)  an  explicit  variable  of  H,  but  not  of  T.  T  Is  the  process 
whose  behavior  the  adversary  may  examine  in  order  to  try  to 
learn  some  new  Information  about  x,  and  the  (structure  of  the) 
host  machine  H  Is  considered  to  be  public  knowledge. 

The  variables  of  T  must  be  considered  to  be  associated 
already  by  the  Implementation  mapping  to  relevant  Variables  In  H 
for  this  tormulatlon  to  make  sense,  (o  and  K  typically  have 
variables  in  common.)  The  role  x  plays  In  H  is  (hopefully)  hidden 
from  T;  T  exists  at  a  level  of  abstraction  (tailored,  perhaps,  to  suit 
the  adversary's  read  rights)  so  that  the  behavior  of  x  cannot  be 
Inferred  from  the  behavior  of  T,  even  taking  into  account  the 
structure  of  H. 


Of  course,  it  could  be  that  different  mappings  which  both  give 
correct  Irrplementatlons  would  give  different  results  for  the 
security  questions.  Given  a  host  and  target,  a  "security  analysis’ 
would  consist  of  characterizing  those  mappings  with  respect  to 
which  H  Implements  T  in  such  a  way  that  x  Is  not  read. 

ACKNOWLEDGEMENT 

We  thank  Sue  Landauer  for  her  careful  reading  of  the 
manuscript,  her  suggestions,  and  her  corrections. 


192 


References 


1.  L.  Marcus,  S.  D.  Crocker,  and  J.  R.  Landau er,  "SDVS:  A 
System  for  Verifying  Microcode  Correctness",  17th 
Microprogramming  Workshop,  IEEE,  October  1984,  pp. 
246-255. 

2.  C.  C.  Chang  jnd  H.  J.  Kelsler,  Model  Theory  (Second 
Edition).  North-Hollcnd.  1977. 

3.  J.  Haipem  and  M.  O.  Rabin,  “A  Logic  to  Reason  about 
Likelihood”,  Fifteenth  Annual  ACM  Symposium  on 
Theory  of  Computing,  ACM,  1983,  pp.  31 0-319. 

4.  S.  Goldwasser,  S.  Mlcali,  C.  Rackoff,  "The  Knowledge 
Complexity  of  Interactive  Proof  Systems",  1984  ACM 
Foundations  of  Computer  Science,  ACM,  1985,  pp. 
291-304. 

5.  V.  Nguyen  and  K.  Perry,  "Do  We  Really  Know  What 
Knowledge  Is?",  Tech,  report  RC  11830,  IBM 
T.  J.  Watson  Research  Center,  April  1936. 

6.  J.  Pearl  and  A.  Paz,  "GRAPHOIDSrA  Graph-based  Logic 
for  Reasoning  about  Relevance  Relations",  Tech,  report 
R-53-L-1 ,  CSD-850038,  Computer  Science  Department, 
UCLA,  April  1986. 

7.  L.  Marcus,  T.  Redmond,  and  S.  Shelah,  “Completeness 
of  State  Deltas".  Tech,  report  ATR-85(83F4)-5,  The 
Aerospace  Corporation,  1985. 

8.  J.  Barwlse  and  S.  Feferman,  Model-Theoretic  Logics, 
Sprlnger-Verlag,  1985. 

9.  Mlctiael  O.  Rabin,  "Decidability  of  second-order  theories 
and  automata  on  Infinite  trees",  Transactions  of  the 
American  Mathematical  Society,  Vol.  141,  1969,  pp. 
1-35. 

10.  Leo  Marcus.  “Implementation  Mapping  between 
Programs",  Tech,  report  ATR-84(8478)-3,  The 
Aerospace  Corporation,  1984. 


19  3 


A  STANDARD  NOTATION  IN  COMPUTER  SECURITY  MODELS 


0.  Sami  Saydjari 
Timothy  Kremann 

National  Computer  Security  Center 
Attn:  Office  of  Research  and  Development,  C3 
9800  Savage  Road 

Fort  George  G.  Meade,  MD  20755-6000 
(301)  85'  -4488 


ABSTRACT 

In  the  burgeoning  field  of  computer  security, 
there  has  been  a  lack  of  standard  notation 
for  representing  madelv.  This  paper  intro¬ 
duces  such  a  notation,  called  Set  Normal  Form 
(SNF) ,  based  on  set  theory.  The  paper 
recasts  the  Bell  and  LaPadula,  Biba  Integ¬ 
rity,  Role  Fnforcement,  and  Multilevel  Object 
models  in  this  notation.  The  standardization 
should  facilitate  the  comparison  of  models  . in 
terms  of  security,  completeness  and  level  of 
abstraction. 

INTRODUCTION 

The  purpose  of  this  paper  is  not  to 
present  new  research  in  computer  security, 
instead,  its  intent  is  to  offer  a  standard 
notation  based  on  set  theory.  The  objectives 
are  to  provide  a  common  language  for  model 
expression  and  facilitate  the  comparison  of 
models. 

Historically,  a  rather  difficult  mixed 
notation  was  adopted  because  of  the  sig¬ 
nificant  impact  of  the  Bell  and  LaPadula 
(BLP)  model.  The  set  theory  notation,  how¬ 
ever,  seems  to  be  more  understandable  and 
flexible.  A  set  theory  casting  of  a  sim¬ 
plified  form  of  the  BLP  model[l],  the  dual 
Biba  Integrity  Model [2],  a  role  enforcement 
model(3],  and  a  Multilevel  Object  (MLO) 
model [4]  are  provided  as  appendices  and 
discussed  in  detail  in  this  paper.  We  shall 
call  this  notational  representation  "Set 
Normal  Form  (SNF)." 

The  essence  of  this  paper  is  in  the 
appendices.  There  is  a  discussion  section 
for  each  of  the  four  appendices  corresponding 
to  the  four  models  rewritten  in  SNF.  The 
purpose  of  each  discussion  section  is  to 
provide:  (1)  highlights,  (2)  clarifications, 
(3)  motivations,  and  (4)  explanations  of  any 
deviations  from  the  original  model. 

The  SNF  castings  of  the  four  models 
chosen  are  intended  to  capture  the  basic 
essence  of  each  model.  Many  of  the  more 
subtle  features  have  been  intentionally  loft 
out  for  simplicity.  The  point  of  these 
representations  is  only  to  show  basic  exam¬ 
ples  of  how  SNF  is  applied. 

DISCUSSION 


introduced  in  this  paper.  We  explain  the 
primitives  once  and  then  use  them  to  provide 
a  shorthand  method  of  referring  to  the  char¬ 
acteristics. 

The  notion  of  "maps-completely-to" 
is  introduced.  Set  A  is  said  to  map-com- 
pletely-to  set  B  if  every  element  in  set  A 
maps  to  some  element  in  set  B.  For  example, 
requiring  every  object  in  a  system  to  have  an 
associated  security  label  is  the  same  as  the 
set  of  objects  maps  completely  to  the  set  of 
classification  labels. 

The  notion  of  "znaps-uniquely-to"  is 
also  introduced.  Set  A  maps-uniquely-to  set 
B  if  no  element  in  A  is  mapped  to  more  than 
one  element  from  B.  For  example,  an  object 
must  have  only  one  classification  associated 
with  it  at  any  time  (  that  is,  it  cannot  be 
bc".h  TOP  SECRET  and  UNCLASSIFIED  at  the  same 
time  ) . 

The  "maps-uniquely-to "  and  "maps- 
completely-to"  primitives  are  combined  and 
called  "maps-fully-to."  All  classification 
labeling  of  objects  and  subjects  must  conform 
to  this  primitive.  In  other  words,  all 
objects  and  subjects  must  have  one,  and  only 
one,  classification  level  associated  with 
them. 

The  power  set  primitive,  PS,  is 
introduced  to  indicate  all  of  the  possible 
subsets  of  a  given  set.  PS  is  not  explicitly 
used  in  the  representation  of  models  in  this 
paper,  but  the  need  for  it  is  anticipated  for 
richer  descriptions. 

The  "is-a-hierarchy-on"  primitive 
(used  in  the  MLO  Model)  describes  the  rela¬ 
tionship  between  containers  and  atoms. 
Contain  rs  are  objects  which  have  descriptors 
of  otl  .ir  objects  while  atoms  are  sex r -con¬ 
tained  objects.  A  hierarchy,  as  defined  in 
appendix  A,  is  used  to  show  the  container- 
atom  relationship  between  objects. 

The  requirements  placed  upon  this 
hierarchy  are  that  its  digraph  representation 
contain  no  cycles.  The  model  requires  that 
each  container's  security  level  dominates  the 
level  of  each  entity  that  it  contains.  The 
actual  hierarchy,  as  defined  here,  is  a 
collection  of  acyclic  rooted  digraphs  which 
may  overlap. 


Primitives 

Notation  primitives  are  descrip¬ 
tions  of  notions  that  are  either  already 
well-defined  in  computer  science  or  common  to 
many  of  the  different  models.  The  motivation 
behind  introducing  these  primitives  is  to 
factor  out  common  characteristics  of  sets 


In  this  hierarchy  we  require  that 
no  container  be  empty.  This  means  that  all 
leaf  nodes  are  atoms  and  all  nonleaf  nodes 
are  containers.  Any  empty  containers  will 
contain  a  special  leaf  node  called  the  null 
atom.  This  is  an  arbitrary  restriction  which 
simplifies  the  MLO  SNF.  The  "is-a-leaf-in" 
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indicates  that  the  corresponding  digraph  has 
no  outgoing  arcs  from  this  node. 

Finally,  the  concept  of  "is-a- 
partial-ordering"  defines  the  standard  math¬ 
ematical  concept  of  a  partial  ordering  on  a 
set.  This  primitive  is  very  important  in 
establishing  order  in  a  normally  unordered 
set.  In  particular  it  allows  the  definition 
of  dominance  for  classification  levels. 

Another  concept  introduced  in  SNF 
is  set  dependence.  The  motivation  is  based 
on  a  confusion  about  which  sets  are  specified 
by  the  user  (or  security  administrator  or 
system  designer)  and  which  sets  are  con¬ 
strained  by  the  choice  of  other  sets.  A 
level-one  set  is  one  which  you  have  complete 
freedom  to  chone.  A  level-two  set  is  one 
that  depends  on,  or  is  constrained  by  a 
level-one  set.  Similarly,  several  levels  of 
dependence  can  be  traced  in  most  models. 

Bell  and  LaPadula  Model 

The  level -one  sets  of  tha  BLP  model 
are  the  compromise  levels  (C_L) ,  objects  (0) , 
and  subjects  (S)  ,  and  the  access  rights  (A) 
that  will  be  used  to  restrict  information 
flow. 

The  set  of  compiomise  levels  is 
simply  an  unordered  enumeration  of  tha  clas¬ 
sification  labels  that  exist  in  the  system- 
for  example,  (SECRET,  UNCLASSIFIED,  CONFIDEN¬ 
TIAL  -  CATEGORY  A) .  The  ordering  of  these 
labels  in  terms  of  sensitivity  is  accom¬ 
plished  by  a  second  set  (P)  defining  a  par¬ 
tial  ordering  on  C_L.  The  levels  in  this  set 
are  called  “compromise"  levels  to  distinguish 
them  from  “integrity"  labels  that  may  be 
associated  with  objects  and  subjects  in  an 
integrity  model  (See  Biba  Integrity,  Appendix 
C)  .  If  there  are  no  other  labeling  schemes 
in  the  system  besides  compromise  levels,  the 
levels  are  often  called  "security  levels." 

The  specification  of  the  set  of 
compromise  levels  as  a  level-one  set  (uncon¬ 
strained  and  unordered)  is  a  deviation  from 
the  original  model.  Security  levels  in  BLP 
are  defined  as  two-tuples  with  the  first 
element  coming  from  a  totally  ordered  (hier¬ 
archical)  set  of  clearance  levels  (e.g.  {TS, 
S,  C,  U})  and  tha  second  element:  from  the 
power  set  of  an  unordered  (flat)  set  of 
categories.  The  partial  ordering  on  the 
security  levels  is  then  defined  in  terms  of 
the  total  ordering  on  the  clearance  levels 
and  subsets  of  categories.  For  example, 
TS.A.B  dominates  S.A  because  TS  is  greater 
than  S  in  the  totally  ordered  set  of  clear¬ 
ance  levels  and  (A)  is  a  subset  of  (A,B). 

The  levels  specification  in  BLP  has 
the  advantage  that  the  determination  of 
dominance  is  a  two-step  operation  and  thus 
the  algorithm  is  said  to  be  "constant  time" 
[  5  ] .  On  the  other  hand ,  there  are  many 
problems  with  this  scheme.  The  enumeration 
of  these  problems  will  be  the  subject  of  a 
future  paper.  The  central  point  here  is  that 
we  view  the  set  of  security  levels  is  as  a 
fundamentally  a  level-one  set  for  maximum 
flexibility. 


The  final  level-one  set  is  that  of 
access  privileges.  The  specification  of  just 
a  read-only  (r)  and  blind-write  (a)  is  a 
deviation  from  the  original  model.  BLP 
specified  four  access  rights:  (1)  read-only- 
observe  but  no  modify,  (2)  execute  -  neither 
observe  nor  modify,  (3)  write  -  modify  and 
observe,  and  (4)  append  -  modify  but  no 
observe.  Note  that  all  of  these  rights  are 
defined  in  terms  of  the  two  more  primitive 
access  privileges  called  "modify"  and  "ob¬ 
serve."  Therefore,  in  the  abstract,  these 
two  primitives  are  the  only  ones  required. 

The  level-two  sets  include  the 
partial  ordering  (P)  on  the  compromise  levels 
(C_L) ,  the  mapping  functions  assigning  clas¬ 
sifications  to  objects  and  subjects  (Fo  and 
Fs) ,  and  the  definition  of  the  universe  of 
all  possible  accesses  between  subjects  and 
objects  (M) . 

The  set  P  is  a  set  of  two-tuples 
defining  a  partial  ordering  on  the  compromise 
levels  (C  L)  .  The  relationship  primitive 
"is-a~partTal-ordering"  is  rigorously  defined 
in  Appendix  A.  It  corresponds  to  the  intui¬ 
tive  notion  of  dominance  in  terms  of  data 
sensitivity.  Because  of  the  transitive 
nature  of  the  definition  of  partial  ordering, 
all  pairs  that  directly  or  indirectly  domin¬ 
ate  each  other  must  be  contained  in  the  set. 
in  other  words,  if  (TS,S)  and  (S,C)  are  in  P 
indicating  that  TS  dominates  S  and  that  S 
dominates  C,  then  (TS,C)  must  also  neces¬ 
sarily  be  in  the  set.  This  may  be  imprac¬ 
tical  to  implement  for  very  large  sets  of 
compromise  levels  (C_L) .  For  an  implemen¬ 
tation,  the  inclusion  of  only  directly  domin¬ 
ating  pairs  would  suffice.  Transitive  clos¬ 
ure  of  the  sat  could  be  computed  on  the  fly. 

The  sets  Fo  and  Fs  assign  classifi¬ 
cation  labels  to  objects  and  subjects,  res¬ 
pectively.  Tha  method  of  making  this  assign¬ 
ment  is  by  the  use  of  the  two-tuples  where 
the  first  element  is  chosen  from  the  set  of 
objects  (or  subjects  in  the  case  of  set  Fs) 
and  the  second  element  is  chosen  from  the 
compromise  level  set.  For  example,  if  (ol, 
TS)  is  a  member  of  Fo,  this  means  that  object 
ol  is  classified  top  secret.  The  sets  Fo  and 
Fs  are  equivalent  to  the  similarly  named 
mapping  functions  in  BLP.  In  this  represen¬ 
tation,  they  will  be  referred  to  as  the 
classification-mapping  sets. 

The  classification-mapping  sets 
depend  on  two  different  level-one  sets.  This 
is  important  since  changes  to  any  element  in 
a  level-one  set  on  which  a  level-two  set 
depends  may  adversely  affect  the  level-two 
set  as  wall.  For  example,  a  change  made  to 
the  set  of  objects  (e.g.  when  a  subject 
writes  to  an  object)  will  impact  on  Fo  since 

it  depends  on  the  set  of  objects  (0)  and  the 
set  of  classification  levels  (C_L).  Further¬ 
more,  a  change  to  C_L  impacts  on  both  Fo  and 
Fs.  This  dependency  is  highlighted  by  the 
organization  of  SNF. 

The  definition  of  Fs  is  a  deviation 
from  the  original  model .  BLP  has  two  mapping 
functions  for  subjects:  fs  and  fc.  Both 
functions  map  subjects-to-levels.  The  level 
assigned  to  a  subject  by  fs  is  the  upper 


1S5 


bound  of  the  level  a  subject  may  take,  where¬ 
as  assigns  the  current  level.  This 
implies  that  fc  is  a  dynamic  assignment  con¬ 
strained  by  fs.  This  conceptual  separation 
has  been  deleted  from  our  representation  for 
simplicity. 

The  separation  of  labeling  func¬ 
tions  described  in  the  original  blp  model  is 
logically  equivalent  to  having  multiple 
subjects,  each  taking  on  one  of  the  classifi¬ 
cations  allowed  to  the  singla  subject  under 
BLP.  For  example,  subject  si  exists  under 
the  unmodified  BLP  scheme,  it  is  currently 
classified  "C,"  and  the  maximum  level  si  can 
take  is  "S."  Assuming  the  levels  are  ordered 
as  {S,C,U},  this  is  logically  equivalent  to 
having  three  subjects,  sll,  sl2,  sl3,  clas¬ 
sified  at  U,  C,  S,  respectively.  This  shall 
be  referred  to  as  the  one-subject-one-level 
approach. 

The  alternative  one-sub ject-one- 
level  approach  is  also  more  satisfying  in 
that  it  promotes  tranquility  of  the  security 
state  of  the  system.  This  is  preferable  in 
that  changes  made  to  any  set  by  any  operation 
on  a  system  require  a  proof  that  the  change 
to  that  set  and  any  sets  that  depend  on  it  do 
not  corrupt  the  security  of  the  system. 

The  final  level-two  set  is  M.  It 
defines  the  universe  of  all  possible  accesses 
that  each  subject  may  have  to  each  object. 
The  security  policy  set,  B,  equal  to  the 
universe  set,  M,  represents  a  completely 
permissive  system  in  which  each  subject  has 
all  possible  access  privileges  to  each  object 
in  the  system.  The  universe  is  then  restric¬ 
ted  by  one  or  more  security  policies  repre¬ 
sented  by  subsets  of  the  set  M  and  inter¬ 
sected  to  form  the  overall  policy. 

As  a  point  of  clarification,  the 
three-tuple  (si,  ol,  r)  in  set  Bsp  means  that 
subject  si  has  read  access  to  object  ol.  It 
is  equivalent  to  entering  the  access  privil¬ 
ege  r  in  the  (1,1)  cell  of  an  access  matrix. 
The  use  of  set  notation  may  seem  awkward  here 
at  first,  but  it  maintains  consistency  with 
the  rest  of  the  notation  and  aliows  a  some¬ 
what  different  perspective  on  access  control 
than  that  provided  by  matrices. 

The  use  of  the  letters  M  and  B  for 
these  sets  may  be  somewhat  confusing  since 
BLP's  definition  for  the  same  terms  are 
different.  As  defined  in  this  paper,  M  is 
the  cross  product  of  the  set  of  subjects  (s), 
the  set  of  objects  (o) ,  and  the  set  of 
accesses  (A)  resulting  in  all  possible  com¬ 
binations  of  elements  chosen  from  each  of 
these  sets,  BLP  defines  M  as  the  access 
matrix  indexed  by  subject  and  object.  Each 
cell  in  the  matrix  M  contains  a  set  of  allow¬ 
able  accesses.  In  this  pape>  sets  beginning 
with  the  capital  letter  B  represent  instan¬ 
tiations  of  security  policies.  The  single 
letter  B  represents  a  security  policy  equal 
to  the  universe  set  M  which  implies  no  restr¬ 
iction  to  any  access.  In  BLP,  B  is  the  power 
set  of  the  universe  set.  In  other  words, 
this  B  represents  all  possible  restrictions 
that  may  be  placed  on  the  universe.  There 
appears  to  be  no  utility  in  using  the  power 
set  of  the  universe  in  our  context  so  we  have 
chosen  to  leave  it  out. 


The  level-three  sets  represent  a 
fairly  significant  departure  from  the  orig¬ 
inal  BLP  model  in  form  but  not  in  content. 
BLP  defines  two  rules  that  restrict  the 
promiscuous  universe  of  full  access,  each  in 
its  own  way.  The  restriction  of  this  set  is 
implicit  since  it  is  specified  by  defining  a 
state  such  that  the  accesses  allowed  adhere 
to  the  rules.  SNF,  on  the  other  hand,  makes 
the  restrictions  of  the  universe  defined  by  a 
rule  explicit  by  the  specification  of  a  set. 
This  set  ultimately  determines  the  subset  of 
the  universe  which  implements  the  security 
policy  associated  with  the  rule. 

The  first  level -three  set,  Bms, 
defines  the  mandatory  security  policy. _  Since 
mandatory  security  is  really  the  combination 

of  restrictions _ on  read  access  by  simple 

security  and  on  write  access  by  the  *-pro- 
perty,  the  set  Bms  is  broken  up  into  two 
explicit  subsets  associated  with  each  of  the 
rules.  These  sets  are  unioned  to  form  Bms- 
those  accesses  allowed  under  the  integrated 
mandatory  security  policy. 

The  subset  Bms_r  represents  the 
read  restrictions  imposed  by  the  simple 
security  property.  The  property  has  been 
summarized  as  meaning  "no  read  up"  in  classi¬ 
fication  level.  For  example,  a  secret- 
cleared  subject  is  prevented  from  reading 
data  in  a  top  secret  object.  Read  access  is 
permitted  only  if  the  level  of  the  subject 
dominates  the  level  of  the  object. 

Similarly,  the  subset  Bms__a  repres¬ 
ents  the  write  restrictions  by  the  *-proper- 
ty.  This  property  has  been  summarized  as 
meaning  "no  write  down"  in  classification 
level.  For  example,  a  secret-cleared  subject 
may  not  write  to  an  unclassified  object  since 
secret  information  could  flow  to  the  object 
thereby  exposing  it  to  unclassified  subjects. 
Write  access  is  permitted  only  if  the  level 
of  the  object  dominates  the  level  of  the 
subject. 

The  second  level-three  set,  Bds, 
defines  discretionary  security  policy.  Bds 
is  an  arbitrary  subset  of  the  universe  of 
promiscuous  accesses  defined  in  set  B.  The 
discretionary  nature  of  the  set  come3  from 
additional  rules  defining  subsets  of  B  over 
which  each  subject  has  dominion.  Dominion 
means  the  discretion  to  includa  or  exclude  an 
element  from  Bds,  thereby  allowing  or  denying 
the  corresponding  access  privilege. 

The  final  level-three  set,  Bs, 
defines  the  unified  security  policy  -  the 
combination  of  mandatory  and  discretionary 
access  control.  The  set  Bms  defines  the 
mandatory  security  policy.  The  set  Bds 
defines  the  discretionary  security  policy. 
These  two  set  are  intersected  to  fora  the 
unified  policy.  The  fact  that  the  combin¬ 
ation  is  done  by  intersection  says  that  if  a 
given  access  privilege  is  denied  by  either 
policy,  it  is  denied  in  the  unified  policy. 
In  this  way,  even  though  an  arbitrarily  large 
subset  of  the  promiscuous  universe  set,  the 
discretionary  access  set  cannot  allow  access 
denied  by  the  mandatory  security  policy 
embodied  In  set  Bms. 


This  representation  of  the  total 
security  policy  as  the  intersection  of  subsi¬ 
diary  policies  allows  simple  extension  to 
include  other  security  protection  policies 
with  these  two  by  simply  intersecting  them 
o  the  final  set.  This,  for  example,  makes 
j  addition  of  type  enforcement  described  in 
Appendix  C  simpler  to  grasp  in  its  relation¬ 
ship  to  the  other  security  policies  with 
which  it  coexists. 


Biba. Integrity  Model 

The  Biba  Integrity  Model  is  essent¬ 
ially  an  exact  parallel  to  the  BLP  model  with 
compromise  levels  (C_L)  replaced  by  integrity 
levels  (I_L) .  The  SNF  description  in  Appen¬ 
dix  B  is  nearly  identical  to  that  of  BLP  with 
the  above  noted  change  propagate’  throughout. 

The  model  is  intended  to  protect 
the  integrity  of  data  in  a  system  so  as  to 
prevent  unauthorized  modification  of  objects. 
For  example,  a  data  base  locating  the  space 
junk  orbiting  the  earth  may  be  unclassified, 
but  the  integrity  of  this  information  is 
critical  to  plotting  a  safe  course  for  space 
craft.  The  Biba  Integrity  Model  attempts  to 
deal  with  this  problem  by  adding  integrity- 
related  labels  to  all  of  the  subjects  and 
objects  and  rentricting  access  to  protect 
critical  files  (objects)  . 

The  innovation  in  the  model  is  not 
in  its  form  (since  it  is  equivalent  to  BLP) 
but  rather  in  the  assignment  and  interpretat¬ 
ion  of  labels.  It  is  difficult  to  make  sense 
of  assigning  integrity  labels  to  subjects. 
The  assignments  necessary  to  provide  integ¬ 
rity  protection  of  certain  types  seems  con¬ 
torted  at  times.  Indeed,  the  author  drops 
parts  of  the  parallel  to  BLP  due  to  an  inabi¬ 
lity  to  ascribe  a  meaning  to  them. 

The  attempt  to  parallel  BLP 
resulted  in  a  somewhat  contorted  model  that 
was  not  powerful  enough  to  fulfill  the  spect¬ 
rum  of  requirements  of  integrity  enforcement. 
For  example,  the  model  cannot  protect  inter¬ 
mediate  file  results  in  a  pipeline  of 
programs  without  requiring  a  substantial 
amount  of  trusted  software. [3]  One  of  the 
most  important  goals  of  a  model  is  to  mini¬ 
mize  the  amount  of  trusted  software  since 
software  verification  is  expensive.  This 
leads  the  discussion  to  the  next  section  on 
role  enforcement.  This  model  addresses  the 
same  integrity  problem,  but  with  much  more 
power. 

R <?jg.  Snf dECCTnenfr-  MeJ. 

The  level-one  sets  of  objects  (0) , 
subjects  (S) ,  and  accesses  (A)  are  as  in  the 
BLP  model  description  above.  The  set  of 
types  (T)  and  domains  (D)  are  new  sets  that 
will  act  as  an  orthogonal  label  set  for 
objects  and  subjects  respectively.  The 
unique  aspects  of  role  enforcement  [3]  are 
based  on  these  two  sets. 

The  first  level-two  set,  FI, 
assigns  types  to  objects.  Notice  that  the 
mapping  need  only  be  complete  -  each  object 
must  have  at  least  one  type  associated  with 


it.  There  appears  to  be  no  need  to  make  the 
mapping  unique  as  for  classification  labels 
in  the  standard  BLP  model .  In  other  words , 
there  appears  to  be  no  needed  restriction  in 
this  policy  that  prohibits  an  object  from 
being  of  more  than  one  type.  Similarly,  the 
set  F2  maps  all  subjects  to  domains. 

The  universe  of  all  possible 
accesses  is  again  defined  as  M  as  in  Appendix 
B  for  BLP. 

The  level-two  set,  F3,  defines  the 
universe  of  all  possible  accesses  between 
domains  and  types  just  as  is  done  above  for 
the  set  M.  Indeed,  if  each  object  is 
assigned  a  unique  type,  and  each  subject  is 
assigned  a  unique  domain,  F3  is  isomorphic 
to  the  universe  set  M. 

The  first  level-three  set,  F4,  is 
defined  as  a  subset  of  F3  that  defines  a 
particular  access  policy.  F4  is  an  arbitrary 
subset  of  F3  in  very  much  the  same  sense  that 
Bds  is  an  arbitrary  subset  of  B.  Indeed, 
under  the  special  condition  stated  above,  the 
analogy  is  exact.  This  brings  up  an  interes¬ 
ting  point.  Is  this  model  a  kind  of  discret¬ 
ionary  access  control,  and  does  it  suffer 
from  “the  same  inherent  weaknesses?  The 
answer  is  no,  but  only  if  the  assignment  of 
labels  is  done  carefully  and  the  mappings  of 
obj ects-to-types  and  subjocts-to-domains 
remains  tranquil  (static) .  Restricted 
changes  could  be  allowed,  but  they  would  have 
to  adhere  to  some  stated  properties  if  they 
are  not  to  corrupt  the  integrity  protection. 

The  set  Brs  is  a  level-three  set 
that  essentially  maps  the  access  restrictions 
imposed  between  domains  and  types  back  to 
restrictions  between  subjects  and  objects. 
Brs,  therefore,  defines  a  particular  role 
enforcement  security  policy.  It  is  a  defined 
subset  of  the  universe  of  all  possible 
accesses  (M)  in  the  same  way  that  Bds  (dis¬ 
cretionary  policy)  and  Bms  (mandatory)  are 
also  subsets  of  M.  Role  enforcement  is 
represented  as  just  another  subsidiary  policy 
in  the  same  form  that  can  simply  be  intersec¬ 
ted  into  the  unified  policy  defined  by  the 
set  Bsl . 

The  unified  policy  set,  Bsl,  is 
defined  as  the  intersection  of  the  BLP 
unified  policy  Bs  (which  combinas  mandatory 
and  discretionary  security  -  see  Appendix  B) 
and  the  policy  enforced  by  role  security. 
This  demonstrates  the  facility  of  adding 
coexisting  security  policies  under  SNF. 


MLO  Model 

In  1985  SYTEK,  Inc.,  produced  an 
MLO  Model  under  a  Rome  Air  Development  Center 
contract.  At  that  time,  we  were  not  able  to 
compare  the  flLO  model  rigorously  with  any 
other  model  due  to  the  lack  of  a  standard 
notation.  In  casting  the  MLO  model  in  SNF  we 
were  able  to  grasp  its  content.  In  this 
paper  we  cast  that  part  of  the  MLO  model 
which  allows  us  to  compare  it  with  BLP .  A 
complete  casting  of  the  MLO  model  will  appear 
in  a  subsequent  paper. 
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MLO  access  attributes  are  treated 
at  a  higher  level  than  BLP.  In  addition  to 
tha  BLP  read  and  write,  the  actual  MLO  set  of 
access  types  includes  the  following:  create, 
destroy,  downgrade,  upgrade,  owner,  clear¬ 
ance,  Discretionary  Access  Table  (DAT) ,  and 
kill.  For  simplifying  the  comparison  with 
BLP,  we  will  consider  only  the  read  and  write 
access  attributes. 

The  set  of  security  levels  (S_L)  is 
the  equivalent  to  the  BLP  SNF  set  of  com¬ 
promise  levels  (CL).  The  subject  and  object 
sets  are  BLP  equivalents  also.  The  set  of 
roles  (RO)  list  all  the  possible  roles  under 
which  subjects  may  operate.  Subjects  may 
operate  in  one  role  at  a  time  (S_RO) . 

The  level-two  sets,  partial 
ordering  (P)  and  object-level  mapping  (Fo) , 
are  BLP  SNF  equivalents.  In  MLO,  however,  we 
have  two  security  levels  associated  with  each 
subject:  the  container  clearance  (Fc)  for 
reference  path  access  and  the  data  clearance 
(Fd)  for  object  access. 

To  model  the  relationship  between 
multilevel  objects  (i.e.  containers)  and 
single  level  objects  (atoms)  the  set  H  is 
defined  with  the  primitive  is-a-hierarchy-on 
(see  Appendix  A) .  The  sat  H  models  both  the 
container-atom  relationship  between  objects 
as  well  as  determines  the  possible  reference 
paths  for  object  access.  For  example,  if  an 
object  oz  is  contained  in  container  oy  which 
is,  in  turn,  contained  by  container  ox,  a 
reference  path  to  oz  would  be  the  ordered 
tuple  <ox,oy,oz>.  The  set  Q  represents  all 
such  sequences  in  H.  H  also  determines  which 
objects  are  atoms  and  which  are  containers  by 
using  the  convention  that  the  leaves  are  the 
atoms . 

Tha  reference  mechanism  in  the  MLO 
model  returns  the  reference  path  which  must 
be  used  to  access  an  object.  The  met  RF 
models  this  mechanism  and  maps  subject-role 
pairs  and  objects  to  reference  paths.  There 
is  only  one  allowable  path  to  an  object  for 
each  subject  and  role  combination.  Frp,  a 
level-five  set,  models  the  association  of  a 
security  level  with  each  path.  Given  a 
subject  in  a  specific  role  accessing  an 
object,  there  is  only  one  path  allowed,  and 
it  has  a  single  security  level  associated 
with  it.  For  example,  in  a  top  secret  doc¬ 
ument  there  is  an  unclassified  paragraph 
which  may  be  only  accessed  if  the  user  has  a 
top  secret  clearance.  The  reference  path 
here  is  opening  the  document  and  then  reading 
the  paragraoh.  This  is  modeled  by  the  use  of 
a  container  clearance  per  subject  and  assign¬ 
ing  top  secret  to  all  reference  paths  to  the 
paragraph.  The  subject's  container  clearance 
must  dominate  tha  level  of  the  reference  path 
used  to  access  the  object. 

Finally,  we  create  tha  sets  Bms_r 
and  Bms_w  which  are  analogous  to  the  BLP 
Bms_r  and  Bms_a  sets.  An  element  (sr,o,r)  of 
Bms~r  implies  that  read  access  is  allowed 
because  the  subject  (s) ,  acting  in  the  role 
(ro) ,  has  a  container  clearance  which  domin¬ 
ates  the  security  level  of  the  reference  path 
to  object  (o)  and  a  data  clearance  which 


dominates  tha  object's  security  level.  This 
is  the  MLO  equivalent  to  simple  security. 

The  MLO  equivalent  to  the  *-proper- 
ty  is  the  set  Ems_w.  An  element  (sr,o,w)  of 
Bms_w  implies  that  write  access  is  allowed 
because  the  subject  (s),  acting  in  the  role 
(ro) ,  has  a  container  clearance  which  domina¬ 
tes  the  security  level  of  the  reference  path 
to  the  object  (o)  and  a  data  clearance  which 
is  dominated  by  the  security  level  of  the 
object. 

The  unified  security  policy  is 
determined  as  in  BLP.  Given  an  arbitrary 
set,  Bds,  which  represents  the  discretionary 
access  controls  and  the  set  Bms  which  is  the 
union  of  Bms_r  and  Bms_w,  the  total  secure 
access  set  is  the  intersection  of  Bms  and 
Bds. 

In  simplifying  the  MLO  model  to 
compare  it  with  BLP  we  ignored  the  concept  of 
users  and  operations.  The  MLO  model  is  much 
more  comprehensive  than  we  present  here: 
however,  we  feel  we  have  accomplished  our 
purpose  of  comparing  it  with  BLP.  The  inter¬ 
esting  problem  of  modeling  parameters  in  set 
theory  will  be  solved  in  the  full  casting  of 
the  MLO  model  in  SNF. 


CONCLUSION 

The  notation  proposed,  SNF,  is  consis¬ 
tently  based  on  set  theory  representations. 
This  has  proven  sufficiently  powerful  to 
represent  the  essence  of  four  different 

security  models.1 

Merely  representing  these  models  in  SNF 
has  given  the  authors  new  insights  into  the 
meaning  and  ramifications  of  these  models. 
SNF  promises  to  greatly  facilitate  the  analy¬ 
sis  of  existing  models  and  the  comparison 
between  models.  Several  follow-up  papers 
based  on  SNF  are  planned. 


1  We  expect  SNF  to  be  rich  enough  to 
represent  the  full  subtlety  of  current  com¬ 
puter  security  models,  however  this  remains 
to  be  shown  by  future  analysis. 
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APPENDIX  A:  Notation  Primitives 

Set  Normal  Form  Construct  Definitions 
07/18/86 

Strings  of  ASCII  characters  are  used  in  place 
of  standard  mathematical  symbols  for  two 
reasons:  we  wish  to  easily  transmit  this 
document  electronically,  and  we  do  not  have 
the  graphics  capability  to  support  editing 
such  a  document.  Realizing  that  these  symbols 
are  near  and  dear  to  the  mathematician's 
heart,  we  will  produce  this  notation,  some¬ 
time  in  the  future,  using  ccandurd  mathem¬ 
atical  symbols. 

1.  maps-completely-to:  Given  sets  A  and  B 
and  M  :«  (  (a,b)  |  a  member-of  A  and  b 
member-of  B),  A  "maps-completaly-to"  B  iff 
for_every  a  member-of  A  there_exists  (a,b) 
member-of  M  for  some  b  member-of  B. 

2.  maps-uniquely-to :  Given  sets  A  and  B  and 
M  :»  (  (a,b)  |  a  member-of  A  and  b  member-of 
B),  A  "maps-uniquely-to"  B  iff  (a,bl)  member- 
of  H  and  (a,b2)  member-of  M  implies  bl»b2 
where  a  member-of  A  and  bl,b2  member-of  B. 

3.  maps-fully-tos  Given  sets  A  and  B,  A 
mapo-fully-to  B  iff  A  maps-uniquely-to  B  and 
A  maps_completely  to  B 

4.  PS (A):  power  set  of  A 

5.  is-a-partial-ordering-on:  Given  set  A 
and  P  :~  (  (al,a2)  |  al,  a2  member-of  A  ),  P 
"is-a-partial-ordering-on"  A  iff 


(i) 

al  -  a2 

or 

(ii) 

(al,a2) , 

(a2„al)  members-of  P  *■> 

al-a2  or 

(iii) 

(al,a3) , 

(a3,a2)  meabers-of  .'P  «> 

(al,a2)  member-of  P  where 

al,a2,a3 

members-of  A 

Comment:  The  three  conditions  specify 
reflexivity,  antisymettry,  and  transitivity 
required  by  a  partial  ordering.  P  captures 
the  dominance  relationship  described  by  BLP. 

6.  is-a-hierarchy-on:  Given  set  A  and  H  :■  { 
(al,a2)  |  al,a2  member-of  A  }  H  "is-a-hier¬ 
archy-on"  A  iff 

(i)  al  not  -  a2  and 

(ii)  for  all  sequences  of  members  of  H 
where 

(al,a2) , (a2,a3) , . . . , (ai,ai+l) , . . . 
,(an-l,an)  is  a  sequence  where 

the  second  element  of  one  pair  is 
first  element  of  the  next  pair  »> 
al  not  -  an 

Comment:  The  two  requirements  specify  that 
(1)  no  container  contains  itself, 
and  (2)  there  are  no  cycles 
within  the  representative  di¬ 
graphs  . 

7.  is-a-leaf-in:  Given  H  is-a-hiararchy-on  A 

then  a  is-a-leaf-in  H  iff 

(i)  for  all  (ai,aj)  member-of  H,  a 
not  -  ai 

Comment:  There  are  no  objects  which  this 

object  contains.  By  our  restrict¬ 
ion  that  all  containers  must 
contain  at  least  the  NULL  atom, 
only  the  atoms  will  satisfy  the 
above  criteria. 

8.  is_a_subset_of :  A  is_a_s  bset_of  B  iff 

(i)  for  all  a  member-of  A,  then  a 
member-of  B 


APPENDIX  B:  Bell  And  Lapadula 


Modified  Bell  and  Lapadula  Model 
Set  Theory  casting 
08/29/85,  09/18/85 


Level-one  Sets:  The  fundamental  sets  of  the 

modeling  system. 

C_L  :»  set  of  all  compromise  levels 

0~:*>  set  of  all  objects 

( data ; files  jpgms ; sub j  ects ; i/o 
devices) 

s  •—  set  of  sll  subjects  (processes ,pgms 
in  execution) 

A  :»  (r,a)  the  set  of  access  rights 

r  means  read-only  access 
a  means  blind-write  access 


Level-two  Sets:  The  sets  which  depend  only 

on  fundamental  sets. 

P  is-a-partiai-ordering-on  C_L 

Def:  11  R  12  denotes  the  dominance 

relation  R  between  C_L  members  11 
and  12.  11  R  12  iff  (11,12)  is  a 

member  of  P.  In  BLP  terms,  II  R 
12  means  level  II  dominates  level 
12. 
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Fo  :-  {  (o,l)  |  o  member-of  0,  1  member-of 
C_L,  and  O  maps-fully-to  C_L) 

Comment:  Fo  is  a  set  that  equivalently 
specifies  the  BLP  function  Fo: 
0  — >  C_L. 

Def:  Given  a  particular  (o,l)  member- 
of  Fo,  Fo ( o)  refers  to  the  level 
1  to  which  object  o  is  mapped  in 
the  tuple . 

Fs  :»  {  (s,l)  |  s  member-of  S,  1  aember- 

of  C_L  and  S  maps-fully-to  C_L) 

Comment:  Fs  is  a  set  that  equivalently 
specifies  the  BLP  function  Fs: 
s  — >  c_L. 

Def:  Given  a  particular  (s,l) 

member  of  Fs,  Fs(s)  refers  to 
the  level  1  to  which  subject  s 
is  mapped  in  the  tuple. 

M  (  (s,o,x)  |  s  member-of  S,  o  member- 
of  0,  x  member-of  A} 

Comment:  M  is  the  set  of  all  possible 
access  between  subjects  and 
objects  independent  of  the 
mapping  functions.  M  is 
essentially  equivalent  to  an 
access  matrix  with  all  of  the 
entries  filled  in  with  full 
access. 


Level-three  Sets:  The  sets  which  depend  on 
level-two  sets. 

Bms  :«  Bms_r  Union  Bms_a 

Comment:  Bms  is  a  subset  of  M  which 
defines  the  access  between 
subjects  and  objects  that  are 

allowed  by  simple-security  and 
the  * -property. 

Bms_r  :»  {  (s,o,r)  \  Fs(s)  R  Fo(o)  } 

Comment:  Bms_r  are  those  accesses 

allowed  by  simple-security. 

Bms_a  :»  {  (s,o,a)  |  Fo(o)  R  Fs(s)  ) 

Comment:  Bms_a  are  those  accesses 

allowed  by  the  ^-property. 

Bds  is_a_subset_of  M 

Comment:  Bds  are  those  accesses  that 
are  allowed  by  discretionary: 
security.  BLP  refers  to  this 
as  matrix  M,  where  M(i,j)  «  r 
means  that  the  ith  subject  has 
read  access  to  the  jth  object. 
This  is  represented  by  the 
triple  (si,  oj,  r)  in  the  set 
Bds  in  SNF. 

Bs  Bms  Intersect  Bds 


allowed  in  a  given  security 
system . 


APPENDIX  C:  Biba  Integrity 

Integrity  Parallel  of  the  Modified  Bell  and 
Lapadula  Model 
Set  Theory  Casting 
09/03/85,  9/18/85 


Level-one  Sets:  The  fundamental  sets  of  the 
modeling  system. 

I_L  :■  set  of  all  integrity  levels 

0  set  of  all  objects 

( data  ?  files ; pgms ; sub j  ects ; i/o 
devices) 

S  set  of  all  subjects  (processes; pgms 

in  execution) 

A  :*  (r,a)  the  set  of  access  rights 

r  means  read-only  access 
a  means  blind-write  access 
Levol -two  Sets:  The  sets  which  depend  only 

on  fundamental  set3. 

P  is-a-partial-ordering_on  l_L 

Def:  11  r  12  denotes  the  dominance 

relation  R  between  I  L  members  11 
and  12.  HR  12  iff  (H,i2)  io  a 
member  of  P.  In  BLP  terms,  11  R 
12  meanB  lavel  11  dominates  level 


Fo  :-  (  (o,l)  |  o  member-of  0,  1  member- 

of  I_L  and  o  maps-fully-to  1) 

Comment:  Fo  is  a  set  that  equivalently 
specifies  the  BLP  function  Fo: 
o  — >  I_L. 

Def:  Given  a  particular  (o,l)  member 
of  Fo,  Fo (o)  refers  to  the  level 
1  to  which  object  o  is  mapped  in 
the  tuple . 

Fs  {  (s,l)  |  s  member-of  S,  1  member- 

of  I_L  and  s  maps-fully-to  1) 

Comment:  Fs  is  a  set  that  equivalently 
specifies  the  BLP  function  Fs: 
S  — >  i_l. 

Def:  Given  a  particular  (s,l)  member 
of  Fs,  Fs (a)  refers  to  the  level 
1  to  which  subject  s  is  mapped  in 
the  tuple. 

M  :■«  {  (s,o,x)  |  s  member-of  S,  o  member- 

of  0,  x  member-of  A) 

Comment:  M  is  the  set  of  all  possible 
access  between  subjects  and 
objects  independent  of  the 
mapping  functions.  H  is 
essentially  equivalent  to  an 
access  matrix  with  all  of  the 
entries  filled  in  with  full 
access . 


Comment:  Bs  corresponds  to  the  set  of 
all  secure  access  triples. 
This  set  defines  all  accesses 
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Level-three  Sets:  The  sets  which  depend  on 
level-two  sets. 


Bms  Bms_r  Union  Bms_a 

Comment:  Bins  is  a  subset  of  i:  which 

defines  the  accesses  between 
subjects  and  objects  that  are 
allowed  by  integrity 
simple-security  and  the 
integrity  * -property. 

Bms_r  {  (s,o,r)  |  Fs(s)  R  Fo(o)  } 

Comment:  Bms_r  are  those  accesses 
allowed  by  integrity 
simple-security. 

Bms_a  :-  {  (s,o,a)  |  Fo(o)  R  Fs(s)  } 

Comment:  Bms_a  are  those  accesses 
allowed  by  the  integrity 
•-property. 

Bds  is_a_subset_of  M 

Comment:  Bds  are  those  accesses  that 
are  allowed  by  discretionary 
security.  BLP  refers  to  this 
as  matrix  M,  where  M(i,j)  -  r 
means  that  the  ith  subject  has 
read  access  to  the  jth  object. 
This  is  represented  by  the 
triple  (si,  oj,  r)  in  the  set 
Bds  in  SNF. 

Bs  :  -  Bins  Intersect  Bds 

Comment:  Bs  corresponds  to  the  set  of 
secure  access  triples.  This 
set  defines  all  access  allowed 
in  a  given  security  system. 

APPENDIX  D:  Role  Enforcement 

Type-Domain  Mechanism  Model  Extension  to  the 
Modified  Bell  and  LaPadula  Model 
Set  Theory  Casting 
09/03/85 


Level-one  Sets:  The  fundamental  sets  of  the 

modeling  system. 

0  :■  set  of  all  objects 

S  :■  set  of  all  subjects 

A  :■  {r,a}  the  set  of  access  rights 

T  :*•  ;',-r  c  of  all  types 

D  set  of  all  domains 


Level-two  Sets:  The  sets  which  depend  only 

on  fundamental  sets. 

FI  :«*  {  (o,t)  |  o  member-of  0,  t  member-of 
T  and  o  maps-complctely-to  t) 

Comment :  Fl  maps  every  object  o  to  some 
type  t.  Fl  corresponds  to  a 
mapping  function  Fl:  0  — >  T. 

F2  : -  (  (s,d)  |  s  member-of  S,  d  member-of 
D  and  s  maps-completely-to  d) 


Comment:  F2  maps  every  subject  s  to 

some  donain  d.  F2  corresponds 
to  a  mapping  function  F2 :  s 
— >  D. 

M  :-  {  (s,o,x)  |  s  member-of  S,  o  member- 

of  0,  x  member-of  A} 

Comment:  M  is  the  set  of  all  possible 
access  between  subjects  and 
objects  independent  of  the 
mapping  functions.  M  is 
essentially  equivalent  to  an 
access  matrix  with  all  of  the 
entries  filled  in  with  full 
access. 

F3  :»  {  (d,t,x)  j  d  member-of  D,  t  member- 
of  D,  x  member-of  A} 

Comment:  F3  is  the  set  of  all  possible 
accesses  between  domains  and 
types . 


Level-three  Sets:  The  sets  which  depend  on 
level-two  sets. 

F4  is_a_subset_of  F3 

Comment:  F4  represents  an  access  matrix 
between  domains  and  types. 

Brs  :■  {  (s,o,x)  |  s  member-of  S,  o 

member-of  0,  x  member-of  A  and 
(d,t,x)  member-of  F4  and  (s,d) 
member-of  Fl  and  (o,t)  member-of 

F2 } 

Comment:  Brs  is  the  set  of  all  accesses 
allowed  between  subjects  and 
objects  in  the  type-domain 
model . 

Bsl  :-  Bs  Intersect  Brs  where  Bs  is  the 
BLR  secure  set 

Comment:  Bsl  represents  the  logical  AND 
of  the  basic  access  rights 
defined  by  the  BLP  model  and 
the  type-domain  extension  to 
that  model. 

APPENDIX  E:  MLO  Model 

Modified  MultiLevel  Object  Model 

Set  Theory  Casting 

05/26/86 


Level-one  Sets:  The  fundamental  sets  of  the 

modeling  system. 

S_L  :■»  set  of  all  security  levels 

0  :«  set  of  all  objects 

(data ; files  jpgms  ?  subjects ; i/o 
devices) 

S  set  of  all  subjects  (processes jpgms 
in  execution) 

A  :«  (r,w)  the  set  of  access  rights 

r  means  read  access 
w  means  write  access 

R0  S"  set  of  all  roles 
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Level -two  Sets: 


The  sets  which  depend  only 
on  fundamental  sets 

p  is-a-partial-ordering_on  S_L 

Def:  H  R  12  denotes  the  dominance 

re^ation  R  between  S  L  members 
11  and  12.  11  r  12  Iff 

(11,.  12)  is  a  member-of  p.  in 
BLP  terms,  11  r  12  means  level 
11  dominates  level  12. 

Fo  :«  {  (o,l)  |  o  member-of  0,  1  member- 

of  S_L  and  O  maps-fully-to  s_L) 

Comment:  Fo  is  a  set  that  equivalently 
specifies  the  MLO  function  Fo: 
0  — >  S_L. 

Def:  Given  a  particular  (o,l)  member- 
of  Fo,  Fo(o)  refers  to  the  level 
1  to  which  object  o  is  mapped  in 
the  tuple. 

Fc  :■*  (  (s,l)  |s  member-of  s,  1  member- 
of  S_L  and  S  maps-fully-to  s_b) 

Comment:  Fs  is  a  set  that  equivalently 
specifies  the  MLO  container 
clearance. 

Def:  Given  a  particular  (s,l)  member 
of  Fc,  Fc(s)  refers  to  the  level 
1  to  which  subject  s  is  mapped  in 
the  tuple. 

Fd  :«  {  (s,l)  |  s  member-of  s,  1  member- 

of  S_L  and  S  maps-fully-to  C_L) 

Comment:  Fd  is  a  set  that  equivalently 
specifies  the  MLO  data 
clearance. 

Def:  Given  a  particular  (s,l)  member 
of  Fd,  Fd(s)  refers  to  the  level 
1  to  which  subject  s  is  mapped  in 
the  tuple. 

H  S“  {  (ol,o2)  |  H  is-a-hierarchy-on  O  & 
(Fo(ol) ,Fo(o2) )  member-of  P) 

Comment:  This  hierarchy  determines  the 
container-content 
relationship,  containers 
contain  referencaa  to  other 
containers  and  atoms.  Atoms 
may  be  leafs  and  can  only 
contain  data.  In  order  to 
maintain  the  leaf  (atom)  - 
non-leaf  (container) 
distinction,  we  have  adapted 
the  convention  that  all  empty 
containers  contain  a  null 
atom. 

SR  :*«  {  (s,ro)  |  s  member-of  S,  ro  member- 
of  RO) 

Comment:  SR  is  set  of  all  permissable 
subject-role  combinations, 


S  RO  is_a  subset_of  SR  and  S  mapa-folly- 
to  RO  in  S_RO 

Comment:  Every  subject  must  be 

associated  with  only  one  role 
at  any  given  time. 


Level-three  Sets:  The  sets  which  depend  on 
level-two  sets. 

M  -  (  (sr,o,x)  |  sr  member-of  SR,  o 

member-of  0,  x  member-of  A) 

Comment:  M  is  the  set  of  all  possible 
access  between  subjects  and 
objects  independent  of  the 
mapping  functions.  M  is 
essentially  equivalent  to  an 
access  matrix  with  all  of  the 
entries  filled  in  with  full 
access. 

Q  :•*  (  q  |  q  is  an  ordered  tuple 

<ol,...,on>  St  for  1  <  i  <  n,  n  >  2, 
oi  member-of  q,  then  (oi,oi+l) 
member-of  H  } 

Comment:  Set  of  all  possible  paths 
constructed  of  pairs  of 
objects  from  H 

AT  :•“  {  o  |  o  member-of  0,  o  Is-a-leaf-in 
H) 

Comment:  In  the  MLO  model,  atoms  can 

contain  only  data  at  a  single 
security  level. 

C  :»  {  o  j  o  member-of  0,  not  a  is-a- 

leaf-in  H} 

Comment:  In  the  MLO  modal,  containers 
can  contain  only  descriptors 
of  other  containers  or  atoms. 


Level-four  Sets:  The  sets  which  depend  on 
level-three  sets. 

RF  :*=  {  (sr,o,q)  |  sr  member-of  SR,  o 

member-of  O,  q  member-of  RF,  (SR.O) 
maps-fully-co  RF,  o-on  where  on  is 
last  oi  in  q) 

Comment:  This  equates  to  the  MLO 

reference  mechanism.  Given  a 
subject-rola  pair  and  an 
object  combination,  there  is 
exactly  one  reference  path 
allowed. 

Level-five  Sets:  The  sets  which  depend  on 
level-four  sets. 

Frp  (  (sr,o,l)  |  (sr,o,q)  member-of 

RF,  1  member-of  L) 

Comment:  Frp(o)  will  be  used  as  a 
shorthand  to  indicate  the 
reference  path  level 
associated  with  an  object  for 
a  given  subject-role  pair. 
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Laval-six  Sets:  Tha  sets  which  depend  on 
level-five  seta. 

Sms  Bms_r  Union  Bms_w 

Comment:  Bms  is  a  subset  of  M  which 
defines  the  access  between 
subjects  and  objects  that  are 
allowed  by  MLO  equivalents  to 
tha  BLP  simple-security  and 
the  *-properties. 

Bms  r  :«  {  (s,o,r)  1  Fc(s)  R  Frp(o)  and 
Fd(s)  R  Fo(o)  } 

Comment:  Bros_r  are  those  accesses 
allowed  given  that  the 
subject's  container  clearance 
dominates  the  reference-path 
level  tor  the  object  and  the 
subject's  data  clearance 
dominates  the  object's 
security  level.  (NO  READ  UP) 

Bms  w  :-  {  (s,o,r)  1  Fc(s)  R  Frp(o)  and 
Fd(s)  R  Fd(s)  ) 

Comment:  Bms__w  are  those  accesses 
allowed  given  that  tha 
subject’s  container  clearance 
dominates  the  reference  path 
level  for  the  object  and  the 
subject's  data  clearance  is 
dominated  by  the  ob j  ect ' s 
security  level.  (NO  WRITE 
DOWN) 

Bds  is_a_subset_of  M 

Comment:  Bds  are  those  accesses  that 
are  allowed  by  discretionary 
security.  MLO  defers  this  to 
implementation  detail,  in 
essence  it  is  an  arbitrary 
subset  of  M. 

Ba  :«  Bms  Intersect  Bds 

Comment:  Bs  is  only  part  of  the  full 
MLO  model  created  by  SYTEK, 
Inc.  We  put  as  much  of  the  MLO 
mcdel  in  SNF  as  necessary  to 
compare  it  to  BLP.  Wa  plan  to 
put  the  full  MLO  model  in  SNF 
as  a  future  paper. 
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ABSTRACT 

Auditing  seldom  plays  a  role  in  detecting 
illegal  attempts  to  access  data  residing  in 
computers.  Instead,  if  audit  data  are  used  at  all, 
it  Is  generally  In  the  form  of  detailed  printouts 
that  are  pored  over  by  the  security  officer  for 
further  evidence  of  wrongdoing  after  illegal 
activity  has  already  been  discovered.  This  paper 
examines  the  issues  involved  in  using  audit  data  to 
detect  Illegal  computer  activity,  and  proposes  an 
audit  system  based  upon  the  results  of  that 
examination. 

INTRODUCTION 

There  are  two  major  sources  of  audit  data 
typically  produced  by  timesharing  operating 
systems  to  provide  a  history  of  system  use.  An 
accounting  system  provides  the  information 
necessary  to  bill  account  holders  for  the  computer 
time  that  they  use,  and  security  logs  provide 
listings  of  attempts  to  use  prlviledged  commands. 
The  information  collected  this  way  that  indicates 
a  security  violation,  if  it  exists  at  all,  is  usually 
too  well  dispersed  within  a  large  volume  of 
similar  but  irrelevant  data  to  be  useful  for  the 
detection  of  that  violation,  instead,  it  is  generally 
used  only  to  confirm  something  already  strongly 
suspected,  or  to  add  additional  evidence  to  that 
already  in  existence. 


Despite  the  poor  performance  of  present 
auditing  techniques  applied  to  security,  a 
combination  of  proper  audit  data  and  tools  for  the 
computer  aided  analysis  of  that  data  should 
provide  a  security  officer  with  the  ability  to 
identify  some  illicit  computer  activities.  The 
remainder  of  this  paper  will  examine  activities 
that  violate  the  security  of  computer  systems, 
determine  what  audit  information  needs  to  be 
collected,  and  describe  how  that  information  can 
be  analyzed  to  detect  undesirable  activity. 

VIOLATING  SECURITY 

At  the  most  fundamental  level,  the 
methodology  for  compromising  information 
security  is  the  same  whether  that  information  is 
contained  within  a  computer  system  or  not.  A 
compromise  occurs  through  some  combination  of  a 
violation  of  trust  and  a  circumvention  of  physical 
and  procedural  safeguards.  If  the  violation 
involves  aspects  of  security  not  intimately  related 
to  the  use  of  a  computer,  then  there  will  probably 
be  little  to  distinguish  the  computer  activity 
involved.  In  this  situation  the  computer  is  merely 
a  tool  being  used  in  the  proper  manner. 

The  situation  of  Interest  is  one  where  the 
safeguards  that  are  being  abused  exist  within  the 
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operating  system  of  a  computer.  If  this  is  the 
case  there  may  be  little  to  distinguish  the  Illicit 
act  except  for  information  regarding  particular 
computer  activity.  The  computer  is  then  no  longer 
a  properly  used  tool  but  is  Instead  a  fundamental 
part  of  the  compromise,  This  type  of  violation  or 
circumvention  of  operating  system  safeguards  is 
commonly  referred  to  as  system  penetration, 

A  PHILOSOPHY  OF  PENETRATION 

When  a  person  perfoims  what  appears  to  be 
a  single  operation  on  a  computer,  they  are 
interacting  with  the  computer  operating  system  at 
a  level  of  abstraction  above  what  is  actually 
occuring.  The  operating  system  that  the  user 
manipulates  is  an  abstract  model  that  has  been 
implemented  with  lower  level  operations.  A 
typical  operating  system  contains  several  such 
levels,  each  model  Implemented  In  the  levels 
below  It.  The  lowest  level  operations  are 
implemented  In  hardware,  it  is  an  Interpretation 
of  the  effects  of  several  hardware  operations  that 
the  user  recognizes  as  the  result  of  any  individual 
command. 

A  properly  constructed  Implementation  must 
exhibit  all  the  properties  that  will  allow  It  to  be 
recognized  as  the  correct  abstraction.  Conversely, 
it  should  not  display  any  properties  not  shared 
with  abstraction  being  Implemented.  Doing  this 
perfectly  is  a  very  difficult  thing  to  ensure.  The 
typical  operating  system  has  a  number  of 
Implementation  flaws  at  each  level  of  abstract 
operation.  When  such  an  inconsistency  is 
discovered,  it  can  often  be  employed  by  a 
sophisticated  user  to  perform  operations  that 
would  otherwise  be  disallowed  as  violations  of 
security. 


Discovering  and  exploiting  inconsistent 
implementations  is  only  one  technique  employed  in 
the  compromise  of  computer  security.  At  its  most 
abstract  level,  an  operating  system  is  still 
complicated  enough  that  administrative  oversights 
and  design  errors  will  sometimes  exist  that  can 
lead  to  properly  unauthorized  access  to  sensitive 
data,  in  such  cases,  penetration  occurs  despite  a 
potentially  correct  Implementation  of  the 
operating  system  design  because  security  has  not 
been  correctly  considered  either  by  the  system 
designers  or  the  system  administrators.  Whether 
the  error  is  made  by  the  implementor,  the 
designer,  or  the  administrator,  penetrations  are 
effected  by  achieving  an  understanding  of  the 
operating  system  and  considering  the 
ramifications  of  using  a  command  or  set  of 
commands  In  an  unanticipated  manner. 

APPLICATION  OF  AUDITING  TO  PENETRATION 

An  auditor  must  collect  data  at  a  relatively 
low  level  of  implementation  for  it  to  be  effective 
in  the  discovery  of  penetrations.  This  ensures 
that  most  of  the  flaws  that  can  be  exploited  exist 
at  levels  of  abstraction  higher  than  that  being 
audited,  maintaining  the  Integrity  of  the  audit 
data.  A  second  requirement  necessary  to  maintain 
the  Integrity  of  the  data  is  for  the  auditor  and  the 
collected  data  to  be  housed  in  a  processor  distinct 
from  that  being  audited.  Otherwise,  the 
successful  penetrator  might  be  able  to  erase  or 
alter  the  data.  Collecting  the  data  at  such  a  low 
level  of  implementation  only  increases  the 
problems  associated  with  the  large  volume  of 
audit  data  Involved,  leading  to  a  third  requirement 
that  a  large  percentage  of  the  potential  data  not  be 
generated  at  all  or  else  be  disposed  of  early  In  tne 
auditing  process.  The  remaining  data  should  then 
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be  processed  by  summarizing  the  effects  of  the 
low  level  commands  upon  data  objects 
representing  relatively  high  level  concepts  of 
system  security.  Whenever  possible,  these  data 
objects  should  become  the  raw  data  that  is 
examined  and  further  processed  for  evidence  of 
security  violations  so  that  the  volume  of  audit 
data  that,  must  be  searched  to  find  a  penetration 
attempt  is  reduced. 

The  security  officer  with  this  kind  of  an 
auditor  will  be  able  to  monitor  system  security  by 
noting  the  access  of  special  purpose  files  used  by 
the  operating  system,  and  by  watching  the  use  of 
commands  with  particular  relevance  to  system 
integrity.  Known  flaws  can  be  carefully  watched. 
Trojan  horse  programs  and  viruses  can,  in  some 
cases,  be  Identified  by  their  access  of  files  and 
patterns  of  information  flow.  Some  covert  channel 
manipulations  can  be  detected  by  their  distinctive 
use  of  system  calls.  The  general  technique  Is  to 
characterize  specific  penetration  techniques  and 
identify  their  use  in  system  activity.  An 
important  point  is  that  much  of  the  Information 
used  in  the  characterizations  will  be  system 
specific. 

The  intent  is  to  put  reliable  Information 
into  the  hands  of  the  security  officer  that  has  a 
direct  bearing  on  possible  attempts  to  circumvent 
the  security  controls  built  into  the  operating 
system  and  achieve  unauthorized  access  to  data. 
The  information  is  retained  on-line  so  that  it  can 
be  further  processed  in  a  manner  directed  by  the 
security  officer.  This  approach  uses  the  unique 
capabilities  of  both  compu. ir  and  human  to 
positive  advantage:  the  computer's  ability  to 
quickly  organize  and  process  data  and  the  human 
talent  for  recognizing  relevant  situations  and 


interrelationships. 

THE  APPROACH 

The  above  approach  was  applied  to  auditing 
the  UNIX  operating  system.  UNIX  was  chosen  for 
several  reasons.  First  among  them  was 
expediency;  I  have  a  PDP  1 1/70  running  a  version 
of  UNIX  and  several  UNIX  experts  at  my  disposal. 
Second,  the  UNIX  system  is  an  almost  Ideal 
candidate.  It  was  developed  as  a  simple  but 
powerful,  general-purpose  operating  system.  The 
fundamental  generality  of  the  individual  commands 
makes  It  possible  to  use  them  in  often  completely 
inappropriate  ways,  tremendously  Increasing  the 
possibilities  of  finding  an  unanticipated 
combination  of  commands  and  arguments  leading 
to  a  violation  of  computer  security.  Modifying 
UNIX  to  produce  the  audit  data  needed  is  easy 
because  it  Is  written  and  maintained  in  C,  a 
high-level  language. 

Like  most  multiuser  computers,  the 
PDP-1 1/70  simulates  multiprocessing  on  a 
computer  with  only  a  single  processor.  The 
hardware  is  designed  such  that  virtual  memory  Is 
mapped  to  actual  memory  in  a  way  enabling  the 
address  space  of  an  Individual  process  to  be  kept 
distinct  from  that  of  other  processes,  A  process 
must  access  all  resources  other  than  its  own 
distinct  address  space  through  requests  to  the 
operating  system,  which  mediates  the  requests 
and  enforces  the  concept  of  process  separation. 

The  UNIX  operating  system  Is  designed 
around  the  central  concept  of  a  file  system.  All 
resources  are  represented  as  files,  greatly 
simplifying  their  access.  Process  separation  is 
maintained  by  requiring  that  processes  have  the 
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proper  permission  before  they  can  access  a  file. 
Each  file  is  marked  with  a  permission  field  that 
indicates  what  class  of  processes  may  access  It 
and  how  it  may  be  accessed.  The  permission  field 
Indicates  read,  write,  and  execute  permissions  for 
three  types  of  processes;  processes  owned  only  by 
the  owner  of  the  file,  processes  owned  my  a 
member  of  the  owner's  group,  and  by  any  process 
regardless  of  ownership.  There  is  an  owner  named 
root  with  special  privilege,  root  has  ownership  of 
the  files  representing  the  disks,  core,  and  so  forth. 
Processes  owned  by  root  also  have  the  privilege  of 
accessing  any  file  regardless  of  the  file's 
permission  field. 

UNIX  Is  implemented  in  the  C  programming 
language,  augmented  with  operations  called 
syscalls.  Syscalls  enforce  the  abstractions  of  a 
file  system  and  the  necessity  for  processes  to 
have  the  privilege  to  access  files.  This  Is  the 
level  at  which  I  chose  to  record  audit  data.  It 
requires  that  the  syscalls  properly  employ  the 
hardware  based  memory  mapping  to  maintain  the 
Illusion  of  virtual  memory,  and  that  the  file 
system  abstraction  is  both  correctly  implemented 
and  properly  enforces  security.  There  is  aiso  some 
circularity  Involved,  since  the  C  language  and  the 
syscalls  run  on  the  UNIX  operating  system.  While 
these  assumptions  are  not  necessarily  completely 
valid,  enough  flaws  exist  beyond  any  in  the 
syscalls  and  the  file  system  to  make  it. 
worthwhile. 

it  was  decided  to  use  syscali  audit  data  to 
construct  representations  of  the  propagation  of 
prlvlledge  (indicating  what  each  process  may 
access),  process  lineage  (keeping  track  of  process 
ownership),  and  file  system  manipulation  by  each 
process  (identifying  potential  Information  flow). 


These  representations  would  be  the  data  submitted 
to  the  security  officer  for  further  analysis. 

Making  the  above  assumptions,  this  Information 
should  be  sufficient  to  identify  many  potential 
breaches  in  information  security  that  can  occur 
through  exploitation  of  the  UNIX  operating  system. 

About  half  of  the  fifty-six  syscalls 
implemented  on  our  version  of  UNIX  (a  modified 
version  6)  were  identified  as  having  an  Impact  on 
the  state  of  the  abstractions  chosen  for  display  to 
the  security  officer,  Aftercareful  consideration, 
twenty  of  these  were  chosen  for  auditing.  The 
goal  was  to  produce  the  most  accurate 
representations  possible  with  the  least  amount  of 
auditing  and  the  smallest  amount  of  processing. 
Syscalls  such  as  pause  were  rejected  as  having  no 
direct  Impact.  Others,  such  as  read  were  rejected 
because  of  their  high  frequency  of  use,  and  because 
their  use  can  be  assumed  from  the  use  of  the  open 
syscali. 

A  Symbolics  LISP  machine  was  chosen  to 
receive  and  process  the  raw  audit  data.  The 
Symbolics  machine  was  chosen  because  of  Its 
suitability  for  symbolic  manipulation  of  lists, 
capability  for  prototyping,  and  attention  to  tools 
for  the  construction  of  elegant  user  interfaces.  A 
major  goal  Is  the  creation  of  a  system  which  Is 
easy  to  use.  The  security  officer  will  be  able  to 
run  background  processes  that  screen  the  incoming 
data  for  particular  events,  and  perform  further 
analysis  in  a  batch  mode. 

CONCLUSION 

An  examination  of  operating  system 
penetration  techniques  and  current  auditing 
methods  indicates  that  most  sophisticated 


violations  of  system  security  will  be  completely 
undetected,  leaving  potentially  no  trace  in  the 
audit  logs  at  all.  Perhaps  the  only  method  of 
Identifying  this  type  of  violation  is  to 
characterize  specific  classes  of  penetrations  and 
attempt  to  recognize  their  occurrence.  To  do  this, 
however,  it  is  necessary  to  audit  data  at  a  lower 
level  of  system  implementation  than  is  currently 
the  practice.  This  data  must  then  be  processed, 
both  automatically  and  with  human  guidance,  to 
identify  Individual  penetration  attempts.  In  order 
to  be  effective,  the  auditor  must,  as  much  as 
possible,  represent  the  audit  data  and  penetration 
characterizations  in  terms  of  high  level 
abstractions  rather  than  the  low  level  audit  data. 
This  reduces  the  amount  of  further  processing  that 
must  take  place.  It  is  also  important  to  give  the 
security  officer  as  much  power  as  possible  to 
describe  characterizations  of  security  violations 
and  guide  the  resulting  search  for  their 
occurrence.  Above  all,  the  proposed  system  Is  a 
tool  Involving  human  participation. 
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TRUST  ISSUES  OF  MACH-1 


Dr.  Martha  A.  Branstad,  Ms.  Pamela  S.  Cochrane, 
Dr.  D.  Elliott  Bell,  and  Mr.  Stephen  T.  Walker 
Trusted  Information  Systems,  Inc. 

P.O.  Box  45 
Glenwood,  MD  21738 


Trusted  Information  Systems,  Inc.,  is  investigating  the 
feasibility  of  creating  a  trusted  version  of  the  Mach-1 
operating  system  being  developed  at  Carnegie-Mellon  Uni¬ 
versity.  Initial  analysis  is  being  done  on  Accent,  the 
progenitor  of  Mach-1,  since  both  systems  are  message- 
based  and  focus  on  ports  (kernel  managed  message  queues), 
as  the  central  abstraction,  although  Accent  has  a  simpler 
process  structure  and  no  memory  sharing.  Accent  is  a 
well-structured  system  designed  with  protection  as  a  sys¬ 
tem  goal.  Consequently,  the  crucial  trust  issue  in  deter¬ 
mining  if  Accent  can  be  made  to  conform  with  the  DoD 
Trusted  Computer  Security  Evaluation  Criteria  (TCSEC)  for 
a  level  B3  system  is  the  ability  to  associate  labels  with 
subjects  and  objects  within  the  system  to  support  manda¬ 
tory  access  control. 

Two  different  approaches  to  labeling,  each  at  a  differ¬ 
ent  level  of  abstraction  with  respect  to  the  system,  merit 
further  investigation.  These  approaches  are:  1)  associate 
labels  with  ports  and  processes  managed  by  the  kernel;  and 
2)  modify  the  existing  access  group  structure  and  use  the 
Authentication,  Authorization,  and  Name  Servers  to  provide 
mandatory  access  control.  This  paper  will  examine  the 
structure  of  Mach-1  and  Accent,  constraints  imposed  by 
the  TCSEC,  and  the  two  approaches  to  labeling  outlined 
above.  This  is  a  preliminary  report  on  a  research  project 
in  its  early  phases;  it  presents  initial  findings  and  strate¬ 
gies,  not  completed  research. 


II.  MACH-1  AND  ACCENT 

Mach-1  is  the  kernel  of  a  distributed  operating  system 
designed  for  a  diverse  set  of  machines,  ranging  from  work¬ 
stations  to  very  high  performance  multiprocessors.  Maeh-1 
is  based  upon  the  Accent  kernel  used  in  the  Spice  distrib¬ 
uted  operating  system  at  Carnegie-Mellon  University. 

Since  Mach~l  bears  a  strong  conceptual  similarity  to 
Accent,  we  will  first  discuss  Accent,  the  simpler  of  the 
systems.  Accent  is  designed  as  a  message-based  system, 
with  processes  eommunicuting  via  messages.  Inter-process 
communication,  process  management,  and  virtual  memory 
management  are  handled  by  the  Accent  kernel.  Other 
operating  system  services  arc  provided  by  servers  outside 
of  the  kernel. 

Messages  in  the  system  are  sent  and  received  via  ports 
which  are  kemel-managed  and  protected  queues  for  mes¬ 
sages.  Access  rights  for  ports  have  three  types:  Own, 
Receive,  and  Send.  Own  and  Receive  are  unique  rights; 
only  one  process  may  possess  Receive  (Own)  rights  for  a 
given  port  at  any  one  time.  Many  processes,  however,  may 
have  Send  rights  to  a  port  at  the  same  time.  Access 
rights  may  be  passed  in  messages.  Each  process  has  (capa¬ 
bilities  for)  a  pair  of  ports  used  for  communication  with 
the  kernel.  The  kernel  maintains  records  of  the  port 
capabilities  associated  with  each  process,  providing  control 
of  port  creation  and  propagation.  Each  process  has  a 
large  virtual  address  space;  Accent  does  not  support  mem¬ 
ory  sharing.  Through  commands  to  the  kernel,  process  cre¬ 
ation  (deletion),  message  sending  (receiving),  and  memory 


Mach-l  is  being  designed  to  run  efficiently  on  mut’i- 
processors.  The  differences  between  Mach-1  and  Accent 
reflect  this  difference  in  design  goals.  Mach-l  maintains 
the  message-based  paradigm  of  Accent,  with  ports  and  port 
access  rights  remaining  the  same.  Processes,  however,  are 
represented  with  separate  abstractions  for  the  environment 
and  the  executable  portion  of  the  process.  A  task  is  the 
environment  in  which  a  collection  of  "lightweight"  pro¬ 
cesses  termed  "t'irrmds"  may  execute.  Ports  are  associated 
with  the  task,  a  >ugh  specific  ports  may  be  designated  as 
primarily  associated  with  a  specific  thread.  Protection  is 
associated  with  the  task,  since  threads  all  share  the  envi¬ 
ronment  provided  by  the  task.  To  facilitate  multiprocessor 
operations,  memory  sharing  is  supported  by  Mach-l. 

In  Mach-l,  as  in  Accent,  the  kernel  mediates  commu¬ 
nication  via  messages.  The  kernel  stores  the  access  rights 
for  ports  and  determines  if  message  transmissions  are  per¬ 
mitted.  Messages  which  carry  access  rights  in  their  con¬ 
tents  must  be  so  designated,  and  the  kernel  updates  its 
tables  as  appropriate  when  such  rights  are  transferred. 
Unless  the  kernel  has  information  concerning  the  port 
access  rights,  the  access  designators  are  not  effective. 

Perhaps  in  contrast  to  what  might  be  expected  in  the 
development  of  a  distributed  system  by  a  university 
research  group,  protection  has  been  a  design  goal  for  both 
Accent  and  Mach-l.  This  view  of  protection  includes  pro¬ 
cess  isolation,  user  authentication,  authorization  for  use  of 
services,  and  discretionary  access  control.  It  does  not 
Include  a  parallel  to  military  security  labeling  (classifica¬ 
tion  and  clearances)  and  mandatory  access  control.  A 
structure  to  support  protection  is  an  integral  part  of  the 
basic  system  design. 

Kernel  mediation  of  message  communication  via  con¬ 
trol  of  port  access  rights  is  a  central  mechanism  of  both 
operating  systems.  The  distributed  system  is  organized  so 
that  major  server  functions  exist  at  both  local  and  central 
sites.  Global  data  stores  and  system  records  are  kept  at 
central  sites  which  are  physically  secured.  Local  sites 
provide  local  functionality  and  communicate  with  central 
servers  through  protocols  that  can  authenticate  servers  to 
one  another,  and  to  users.  Encryption  may  be  used  to 
secure  communication  lines.  Special  servers  handle  user 
identification  and  authentication  on  the  system.  As  indi¬ 
cated,  protocols  of  communication  with  central  authentica¬ 
tion  servers  can  be  used  to  authenticate  users  to  servers, 
and  vice  versa.  Central  servers  can  act  as  key  distribution 
centers. 

Discretionary  access  control  is  provided  by  the  Autho¬ 
rization  Server  and  the  Name  Server  in  conjunction  with 
the  Authentication  Server.  The  Authorization  Server  main¬ 
tains  access  group  membership  for  each  user  via  values  for 
two  entities,  the  primary  and  secondary  access  groups. 
Group  membership  is  determined  at  login  and  communi¬ 
cated  to  the  Authentication  Server,  The  Name  Server* 
maintains  Access  Control  Lists  (ACLs)  associated  with  each 
named  object.  When  files  or  services  are  requested  from 
the  Name  Server,  it  compares  the  access  group  member¬ 
ship  (acquired  from  the  Authentication  Server)  against  the 
ACL  to  determine  if  access  to  the  named  object  is  author¬ 
ized. 
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Although  there  has  been  considerable  concern  for 
attention  paid  to  providing  protection  in  Mach-1  a.  .1 
Accent,  neither  would  currently  qualify  as  a  DoD  trusted 
computer  system  with  more  than  discretionary  access  con¬ 
trol.  Missing  from  both  systems  is  any  mechanism  that 
corresponds  to  sensitivity  classes  for  subjects  and  objects. 
Sensitivity  labels  and  a  mechanism  that  uses  them  to 
enforce  mandatory  access  control  must  be  added  to  the 
CMU  systems  to  provide  a  basis  for  a  stronger  trusted 
computing  capability.  For  our  investigations  we  have  tar¬ 
geted  B3  as  the  goal. 


Ill.  APPROACHES  TO  MANDATORY  ACCESS  CONTROL 
IN  ACCENT 

Discussions  with  CMU  researchers  have  probed  two  dif¬ 
ferent  approaches  to  providing  mandatory  access  control: 
1)  associate  labels  with  ports  and  processes  managed  by 
the  kernel,  and  2)  modify  the  existing  access  group  struc¬ 
ture  and  use  Authentication,  Authorization,  and  Name 
Servers  to  provide  mandatory  access  control. 

Approach  1,  Kernel  Mediation,  would  require  an  exten¬ 
sion  to  the  port  access  mechanism  to  provide  sensitivity 
labeling.  The  kernel  would  check  for  sensitivity  label 
mis-match  while  mediating  port  access  rights.  Although  the 
Kernel  Mediation  approach  would  involve  modification  to 
the  kernel,  the  basic  mediation  mechanism  already  exists. 
This  approach  is  consistent  with  the  TCSEC  B3  level 
mechanism  for  mandatory  access  control  with  minimization 
of  the  TCB. 

Approach  2,  Server  Mediation  would  use  existing 
Accent  servers  to  provide  mandatory  access  control  as  well 
as  the  discretionary  control  they  currently  provide.  Modi¬ 
fications  to  both  duta  structures  and  control  code  in  the 
servers  would  be  required,  but  no  modification  to  the  ker¬ 
nel  itself  is  anticipated.  This  approach,  which  labels  and 
controls  objects  visible  to  users  of  the  system,  should  be 
adequate  to  support  a  B2  or  B3  system. 

Both  of  the  above  approaches  will  be  discussed  in 
greater  detail  in  the  remainder  of  this  paper,  although  the 
Kernel  Mediation  approach  has  been  the  focus  of  most  of 
our  energy.  It  should  be  noted  that  either  approach,  when 
transferred  to  the  Mach-1  system,  must  deal  with  the  issue 
of  multiple  threads  (executable  units)  in  a  single  protection 
domain  provided  by  a  task;  an  issue  in  conflict  with  literal 
interpretation  of  TCSEC  requirements  for  an  isolated  pro¬ 
tection  domain  for  each  process.  Since  threads  appear  to 
be  fundamental  to  achieving  effective  performance  for 
multiprocessor  systems,  however,  this  separable  issue  should 
be  considered  as  a  point  for  future  interpretation  of  the 
TCSEC. 

A  number  of  other  features  must  be  provided  in  order 
to  qualify  as  a  trusted  computing  base  (e.g.,  auditing, 
trusted  path);  however,  since  they  are  not  central  con¬ 
cepts,  they  are  not  being  considered  at  present.  The 
implications  of  the  memory  sharing  permitted  in  Mach-1 
and  the  inheritance  of  both  memory  and  ports  rights  upon 
task  creation  have  not  yet  been  considered,  and  may  also 
significantly  impact  issues  of  trust;  the  same  is  true  for 
resource  management  approaches.  This  paper  presents  ini¬ 
tial  findings  and  strategies  of  research  in  progress,  not  the 
results  of  a  completed  research  effort. 


IV.  KERNEL  MEDIATION  APPROACH 

B3  criteria  require  sensitivity  levels  associated  with  all 
subjects  and  objects  in  the  system  and  mediation  of  all 
access  of  subjects  to  objects  based  upon  these  labels. 
Subjects  are  active  entities  corresponding  to  users.  In  the 
Accent  system,  processes  assume  the  role  of  subject,  and 
as  such  should  be  labeled. 


Objects  are  the  passive  entities  and  in  tradition;-., 
systems  correspond  to  memory  objects  (data  elements;,  tr. 
Accent,  each  process  has  its  own  virtual  address  space  to 
define  its  virtual  memory.  This  virtual  address  space  has 
meaning  only  with  respect  to  its  associated  process  and  is 
accessed  only  by  that  process.  Since  the  virtual  address 
space  is  so  intimately  associated  with  the  process,  and 
accessible  only  within  the  process  (or  in  conjunction  with 
tne  process's  kernel  port),  it  should  be  considered  an 
indivisible  part  of  the  process  and  be  labeled  by  the  pro¬ 
cess  label.  This  implies  that  the  entirety  of  a  virtual 
address  space  is  at  the  same  sensitivity  level  as  that  of 
its  process. 

Ports  provide  a  unifying  abstraction  for  the  design  of 
the  Accent  kernel  and  a  focus  for  access  control  in  the 
system.  Communication  between  processes  (request  for 
services  from  the  kernel  and  other  servers,  and  the  trans¬ 
fer  of  information)  is  accomplished  by  sending  messages  to 
ports  and  receiving  messages  from  ports.  The  actual  ports, 
or  message  queues,  are  maintained  and  protected  by  the 
kernel.  Since  ports  provide  the  communication  conduit  and 
the  access  mechanism  to  process  objects  (and  to  their 
associated  data  and  services)  within  Accent,  and  are  not 
uniquely  associated  with  processes  (since  ownership  rights 
to  them  can  be  transferred),  ports  should  be  labeled. 

Labels  should  be  associated  with  ports  and  processes  in 
the  Accent  kernel.  Since  the  primary  structures  used  to 
define  and  maintain  both  processes  and  ports  exist  internal 
to  the  kernel,  these  are  accessible  only  to  the  kernel 
process  and  are  protected  from  tampering  by  other  pro¬ 
cesses.  Initial  examination  suggests  that  the  label  associ¬ 
ated  with  a  process  be  stored  in  the  PCBHandle  and  the 
port  label  in  PortRee.  Labels  will  require  two  fields: 
SeeurityClassifieation  and  SecurityCategory. 

At  the  time  the  user  would  log  onto  the  trusted  sys¬ 
tem,  the  Authorization  Server  would  determine  the  values 
of  tltese  fields,  based  on  the  user's  requested  sensitivity 
level  for  the  session.  The  validity  of  the  request  would  be 
determined  by  the  Authorization  Server,  based  on  the 
user's  maximum  sensitivity  level  as  recorded  in  the  Autho¬ 
rization  Server's  data  structures.  The  Authorization  Server 
would  be  modified  either  to  insert  this  information  directly 
into  the  PCBHandle  record  or  to  supply  the  information 
for  another  procedure  to  modify  the  PCBHandle. 

In  the  case  of  Port  objects,  the  NewPort  procedure 
would  store  the  fields  of  the  creating  process's  PCBHandle 
record  into  the  PortRee  of  the  new  port.  This  information 
would  have  to  be  duplicated  in  the  PortRee,  since  the 
port's  Procld  becomes  "INTRANSIT"  (NPROC  +1)  when 
ownership  and  receiver  access  rights  are  passed  between 
processes,  eliminating  any  possibility  of  verifying  that  the 
process  receiving  port  rights  is  permitted  to  do  so. 

Since  enforcement  of  access  policies  would  occur  at 
the  time  Send,  Receive,  or  Ownership  privileges  were 
granted,  there  would  be  no  need  to  enforce  these  policies 
during  message  queueing  or  dequeuing  as  well,  except  when 
the  message  being  sent  included  port  access  rights.  The 
IPC  routines,  GiveSendRights,  Give.Receive-Rights,  and  Giv- 
eOwnership,  would  have  to  be  modified  to  check  the  label 
and  classification  fields  of  the  PortRee  against  those  in 
the  PCBHandle  record  of  the  process  acquiring  the  rights, 
to  ensure  that  the  acquiring  process  had  a  valid  right  to 
access. 

Discretionary  access  control  would  be  provided  by  the 
Authorization,  Authentication,  and  Name  Servers  using 
access  group  membership  and  ACLs,  as  is  currently  done  in 
Accent.  We  have  not  yet  investigated  I/O  handling  and 
window  interfaces  (currently  residing  within  the  Accent 
kernel  for  performance  reasons).  Both  areas  may  require 
significant  redesign  to  accommodate  TCSEC  constraints. 
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V.  SERVER  MEDIATION  APPROACH 

Significant  attention  has  been  devoted  in  the  existing 
Accent  system  to  issues  of  access  control.  Built  on  top  of 
the  Accent  kernel,  its  control  of  access  tlirough  the  use  of 
ports  is  a  collection  of  system  processes,  or  servers,  which 
work  together  to  provide  access  control  of  named  objects. 
Th~  Authentication  Server  is  called  during  the  login  pro¬ 
cess  to  verify  that  the  user/password  combination  is  valid. 
The  Authentication  Server  interacts  with  the  Authorization 
Server  to  acquire  the  password  associated  with  any  given 
user,  and  the  access  group  membership  of  the  user.  If  the 
user/password  match  is  valid,  the  Authentication  Server  1) 
establishes  a  port  associated  with  the  user,  2)  records  the 
access  group  membership,  anu  3)  returns  the  Name  Server 
port  to  the  user. 


login  to  the  trusted  Accent  system).  This  mechanism 
would  give  the  user  access  to  the  object  but  prevent  the 
user  process  from  possessing  (and  transferring)  port  access 
rights. 

Children  spawned  by  a  process  would  be  at  the  same 
sensitivity  level  as  the  parent  process  and  could  inherit 
access  rights  held  by  the  parent  without  violating  manda¬ 
tory  access  controls.  The  Mediation  Server  would  inter¬ 
vene  and  hold  ports  only  for  transactions  between  pro¬ 
cesses  at  differing  sensitivity  levels. 

We  conjecture  that  inserting  the  Mediation  Server  into 
the  object  access  path  for  selected  transactions  should  not 
affect  system  performance  too  severely. 


Access  group  membership  is  determined  by  the  values  VI.  CONCLUSIONS 

of  the  primary  access  and  secondary  access  groups  to 

which  the  user  is  a  member.  Each  primary  group  is  The  Accent  and  Mach-1  operating  system  kernels  are 

uniquely  associated  with  a  single  user.  Secondary  groups  very  well-designed,  and  appear  to  provide  a  solid  base  upon 

may  have  both  users  and  other  secondary  groups  as  mem-  which  to  structure  trusted  versions.  Both  systems  provide 

bers.  These  records  are  kept  by  the  Authorization  Server,  discretionary  access  control  which  would  satisfy  C2  level 

which  determines  access  group  membership  at  login  by  per-  ratings.  (Other  C2  level  constraints,  such  as  auditing 

forming  the  union  of  the  transitive  closure  of  the  second-  requirements,  would  require  non-substantive  modifications.) 

ary  access  group  memberships.  Our  current  investigations  indicate  that  the  Accent  system 

could  be  modified  to  generate  a  viable  B3  level  operating 
When  the  user  wishes  to  acquire  files  or  services,  he  system.  The  Kernel  Mediation  approach,  with  labeling  of 

interacts  with  the  Name  Server.  The  Name  Server  provides  all  subjects  and  objects  and  a  minimized  TCB,  is  a  strong 

a  port  for  a  named  object  only  if  the  user  process's  access  candidate  for  B3.  Estimates  of  the  performance  of  such  a 

group  membership  (acquired  via  interaction  of  the  Name  trusted  version  have  not  yet  been  made,  but  we  conjecture 

Server  with  the  Authentication  Server)  corresponds  to  the  that  the  penalties  imposed  by  proposed  modifications  to 

ACL  associated  with  the  requested  named  object.  This  the  kernel  should  not  be  severe.  Required  modification  to 

mechanism  of  access  groups  and  ACLs  is  adequate  to  sup-  control  I/O  and  window  management  may  alter  this  perfor- 

port  discretionary  access  control  and  can  be  extended,  with  mance  prediction,  however.  The  Server  Mediation  approach 

the  addition  of  labels,  to  support  mandatory  access  control.  presents  a  somewhat  weaker  but  still  viable  case  for  B3. 

Performance  should  not  be  affected  too  adversely  by  the 
The  mechanisms  described  above  exist  in  the  current  mediation  required  on  transactions  that  cross  sensitivity 

Accent  system.  The  same  server  interactions  (with  modifi-  levels, 

cations)  can  be  used  as  the  basis  for  adding  labels  and 

mandatory  access  control.  Labels  can  be  associated  with  The  brevity  of  our  study  has  not  permitted  detailed 

users  and  kept  in  data  structures  maintained  by  the  Autho-  examining  the  generalization  of  the  kernel  mediation 
rization  Server.  The  current  sensitivity  level  for  a  session  approach  to  the  Mach-1  system,  although  we  are  convinced 

would  be  established  at  login  time;  it  could  be  less  tlian  that  it  will  necessitate  more  significant  modifications  than 

maximum  clearance  level  of  the  user.  The  Authentication  required  in  Accent  and  a  broader  interpretation  of  the 

Server  would  keep  information  on  the  session  level  along  TCSEC.  Nevertheless,  a  trusted  version  of  Mach-1  seems 

with  the  access  group  information  of  the  user  that  it  pre-  achievable, 
viously  maintained.  All  processes  initiated  by  the  user 

would  operate  at  session  sensitivity  level,  but  they  would  We  are  embarking  upon  further  investigation  of  both 

not  have  actual  labels  associated  with  process  control  data  approaches,  with  Kernel  Mediation  being  the  focus  with  the 

structures.  The  session  level  for  the  process,  maintained  highest  priority,  since  it  is  the  most  fundamentaL  It 

by  the  Authentication  Server,  would  suffice.  appears  that  the  memory  sharing  permitted  in  Mach-1  will 

necessitate  a  stronger  concept  of  memory  object  (capable 
When  a  named  object  is  created,  a  label  would  be  of  having  an  associated  Intel)  than  is  needed  in  Accent, 

associated  with  it  based  upon  the  session  sensitivity  level.  The  Server  Mediation  approach  has  second  priority.  Trust 

The  object  and  its  label  would  be  "registered"  with  the  requirements  are  likely  to  suggest  modifications  in  data 

Name  Server.  When  attempting  to  access  the  object,  the  structures,  algorithms  for  access  control  interpretation,  and 

Name  Server  would  check  the  session  level  (via  interaction  organization  of  functions  within  the  various  servers, 

with  the  Authentication  Server)  against  the  object  label,  in 
addition  to  an  ACL  check  against  access  group  membership 

of  the  user,  to  provide  both  mandatory  and  discretionary  VH.  ACKNOWLEDOMENTS 

access  checks. 

We  wish  to  thank  Richard  Rashid  of  CMU,  and  mem- 
If  access  is  permitted,  the  Name  Server  would  return  bers  of  his  research  group,  for  the  information  provided  to 

port  access  to  the  specific  object  requested.  If  t.te  tran-  us  in  technical  discussions  of  the  Accent  and  Mach-1  sys- 

saction  involves  process  and  object  at  the  same  sensitivity  terns,  ’’’heir  assistance  has  been  invaluable, 

level,  port  access  rights  to  the  object  would  be  conveyed 
by  the  Name  Server  directly  to  the  process.  If  the  tran¬ 
saction  involves  process  and  object  at  different  sensitivity 
levels,  a  Mediation  Server  would  be  introduced  as  an 
intermediary,  The  Mediation  Server  would  be  given  actual 
port  access  rights,  an  object  ID,  and  the  associated  process 
identity;  the  user  process  would  be  provided  with  the 
object  ID.  Actual  access  to  the  object  would  be  made  by 
the  user  process  through  the  Mediation  Server,  using  the 
object  ID.  (The  user  process  would  acquire  a  port  for  the 
Mediation  Server  from  the  Authentication  Server  during  the 
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AN  OVERVIEW  OF  THE  DoD  COMPUTER  SECURITY  RDT&E  PROGRAM 


Panel  Chairman,  Mr.  Lawrence  Castro 
Chief  of  the  Office  of  Research  and  Development 
National  Computer  Security  Center 


The  purpose  of  this  panel  is  to  inform 
the  audience  of  the  progress  of  and  plans 
for  the  Research,  Development,  Testing,  and 
Evaluation  (RDT&E)  efforts  sponsored  by  the 
Department  of  Defense  (DoD)  Computer  Security 
Program  (CSP) .  The  presentation  is  organized 
according  to  the  five  distinct  areas  of  the 
R&D  program:  Secure  Architecture,  Secure 
Database  Management  Systems  (DBMS's),  Network 
Security,  Modeling  and  Verification,  and 
Aids  to  Evaluation. 

The  first  part  of  the  presentation  will 
allow  each  panel  member  to  describe  the 
status  of  his  area's  current  programs  and 
new  initiatives  for  FY87.  Among  the  new 
initiatives  to  be  described  is  the  consoli¬ 
dated  program  for  producing  a  multilevel 
secure  workstation.  The  participating  panel 
members  from  the  three  military  service  labs 
will  describe  the  support  they  are  providing 
to  the  CSP.  Following  this,  the  panel  will 
entertain  questions  from  the  floor. 

Panel  Members: 

Mr.  Wayne  Weingaertner ,  Office  of 
Research  and  Development  (R&D) , 
National  Computer  Security  Center 
(NCSC) ,  Secure  Architecture 

Dr.  John  Campbell,  Office  of  R&D, 
NCSC,  Secure  DBMS 

Mr.  George  Stephens,  Office  of  R&D, 
NCSC,  Network  Security 

Dr.  Sylvan  Pinsky,  Office  of  R&D, 
NCSC,  Modeling  and  Verification 
and  Aids  to  Evaluation 

Mr.  H.  Lubbes,  Space  and  Naval 
Warfare  Systems  Command  (SPAWAR) 

Mr.  John  Faust,  Rome  Air 
Development  Center  (RADC) 

Mr.  John  Preusse,  Army  Communica¬ 
tions  and  Electronic  Command 
(CECOM) 

niwnrmwpv 
■LOtt  v3  X  1 

The  goal  of  the  DoD's  CSP  is  to  provide 
a  quantum  increase  in  the  security  available 
to  the  nation's  automated  information 
systems.  To  achieve  this  goal,  the  NCSC  has 
a  three-pronged  strategy.  The  first  major 
component  of  that  strategy  involves  a  massive 
retrofit  of  security  features  into  existing 
systems.  The  emphasis  here  will  be  on  rais¬ 


ing  all  federal  computers  to  a  controlled 
access  protection  level  (the  C2  level  in  the 
DoD  Trusted  Conputer  System  Evaluation 
Criteria)  of  trust  or  better  by  1988.  The 
second  prong  of  this  strategy  seeks  to 
foster  widespread  availability  of  systems 
through  the  verified  design  lev»l  (Al)  by 
1990.  The  third  part  of  the  strategy  is  to 
develop  techniques  to  extend  assurances  well 
beyond  Al  in  order  to  offer  adequate 
protection  for  our  most  sensitive 
applications. 

Federal-level  policy  changes,  new 
operational  procedures,  and  an  aggressive 
R&D  program  were  required  to  effectively 
implement  the  strategy.  The  R&D  program 
contributes  to  the  first  part  of  the 
strategy  through  a  concentrated  effort  to 
enhance  some  existing  systems.  The  Computer 
Security  RDT&E  Program  provides  the  means  to 
experiment  with  the  efficacy  of  various 
enhancement  options  — functions  or  features 
that  might  be  added  through  enhancement, 
such  as  providing  authentication,  labeling, 
or  auditing.  With  respect  to  the  second 
portion  of  the  strategy,  the  R&D  program 
should  continue  to  provide  the  technological 
support  necessary  in  achieving  an  Al  system. 
Areas  of  support  include  stabilizing  and 
improving  verification  environments; 
providing  background  material  for  refining 
security  criteria  — particularlyfor 
networks;  refining  security  models  that 
would  serve  as  the  point  of  departure  in  the 
development  of  Al  systems;  and  finally, 
developing  Al  demonstration  systems 
themselves.  In  accomplishing  the  third 
portion  of  the  strategy  —  going  beyond  Al 
and  transferring  research  breakthroughs  into 
marketable  products  — tbe  entire  burden 
falls  on  the  RDT&E  Program. 

THE  RESOURCES 

The  Computer  Security  RDT&E  Program  is 
a  cooperative  undertaking  led  by  the  NCSC 
with  the  full  participation  of  the  Army, 
Navy,  Air  Force,  Defense  Communications 
Agency,  and  Defense  Intelligence  Agency. 

Beginning  with  the  FY84  budget,  DoD 
RDT&E  funds  for  computer  security  were 
consolidated,  allowing  the  program  build  to 
be  centralized  while  permitting 
decentralized  execution.  The  FY86  program 
represents  the  third  year  of  consolidation 
and,  like  the  two  before  it,  provides 
specifically-identified  funds  to  be  executed 
by  several  DoD  components.  Consolidation, 
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as  prescribed  in  DoD  Directive  5215.1, 
avoids  unnecessary  duplication  among  DoD 
components.  Decentralized  execution  of  the 
program  by  the  DoDCSC  and  the  DoD  components 
takes  full  advantage  of  the  scarce  expertise 
needed  to  provide  technical  oversight  of 
contracts  dealing  with  the  highly  technical 
field  of  computer  security. 

THE  PROGRAM 

To  most  effectively  meet  our  challenge 
of  transferring  research  breakthroughs  into 
marketable  products,  we  have  channeled  our 
efforts  into  the  five  distinct  areas  already 
mentioned.  These  five  subprograms  explore 
particular  aspects  of  computer  security 
research  and  development  and,  when  combined, 
provide  a  solid  program  spiraling  past  the 
state  of  the  art  and  into  new  technological 
frontiers. 

Secure  Architecture  addresses  the 
design  and  implementation  of  trusted 
computing  bases  (TCb's).  A  TCb  is  the 
hardware  and  software  mechanism  within  a 
computer  system  that  enforces  security.  Our 
current  thrust  is  to  push  the  edge  of  tech¬ 
nology  for  TCB's.  In  addition,  we  are 
investigating  kernel-based  systems,  office 
automation  and  personal  computers  (PC's), 
security  enhancement  of  current  systems,  and 
advanced  architecture. 

Security  kernels  are  the  classical 
means  of  providing  security  in  a  TCB.  A 
security  kernel  is  a  portion  of  the 
operating  system  that  runs  in  its  own 
domain,  separate  from  the  normal  operating 
system  code,  intercepting  any  operation  that 
has  security  relevance.  Last  year, 
Honeywell's  kernel-based  Secure 
Communications  Processor  (SCOMP)  was 
successfully  evaluated  and  received  the 
Center's  highest  rating. 

The  prolific  growth  of  office 
automation  and  PC  equipment  and  software 
within  the  Federal  Government  is  another 
area  of  research  concern.  Little 
consideration  has  been  given  to  the  security 
aspect  of  these  stand-alone  and  netted 
office  automated  systems.  Non-secure  PC's, 
for  example,  negate  the  security  provided  by 
even  the  highest-rated  host  because  labels 
used  within  secure  computers  that  indicate 
the  security  level  of  the  data  are  lost  once 
data  is  transferred  to  a  PC.  Security 
enhancement  will  be  targeted  at  next 
generation  PC's  since  many  of  the  current 
generation  PC's  are  single-state  machines 
and  cannot  support  security. 

Providing  security  enhancement  of 
existing  commercial  operating  systems  that 
process  classified  information  at  inadequate 


security  levels  is  a  near-term  solution. 
Under  this  task,  we  are  incorporating 
security  into  the  UNIX  System  V. 

Advanced  security  architecture  work 
provides  new  and  different  architectures  for 
secure  computers.  The  current  effort  in 
this  area  is  the  Secure  Ada  Target  (SAT). 

The  SAT  takes  a  novel  approach  towards 
providing  security  in  that  it  incorporates  a 
separate  security  processor.  Placing  the 
security  mechanism  into  a  separate  processor 
has  notable  advantages  over  the  kernel-based 
approach.  Because  its  architecture  shares 
security-related  portions  of  the  system  with 
nonsecurity-related  parts,  the  kernelis  open 
to  attack.  A  separate  security  processor, 
however,  prevents  a  user  process  from 
accessing  the  security-relevant  portions  of 
the  system.  A  favorable  side  effect  of 
security  processors  is  an  improvement  in 
performance  because  it  removes  the  security 
processing  load  from  the  main  processor. 

This  advanced  architecture  has  completed 
initial  design  phase,  and  a  prototype  of 
this  computer  should  be  available  in  1988. 

Multilevel  database  management  security 
R&D  has  received  far  less  attention  than  has 
secure  operating  systems.  In  the  summer  of 
1982,  the  Air  Force  and  the  National  Science 
Foundation  cohosted  a  workshop  of  experts  in 
DBMS  to  examine  the  security  problem.  Three 
recommendations  resulted:  (1)  provide  near- 
term  relief  —  it  is  desperately  needed  and 
achievable;  (2)  for  the  mid-term,  develop 
workina  demonstrations  of  high-leverage 
applications;  and  (3)  conduct  long-term 
research  in  the  theoretical  and  practical 
foundations  of  secure  multilevel  DBMS's. 
Current  and  planned  programs  have  made  some 
progress  towards  achieving  these  goals,  but 
there  has  been  no  breakthrough  that  substan¬ 
tially  improves  DBMS  security. 

The  focus  of  the  Secure  DBMS  subprogram 
is  on  compromise  and  integrity  protection  to 
databases  and  their  related  components. 

This  subprogram  is  comprised  of  three 
research  areas:  trusted  prototypes,  studies 
and  analyses,  and  advanced  DBMS 
architectures.  An  effort  to  secure  an 
existing  DBMS  entitled  MISTRESS  is  now  under 
way.  Researchers  are  conducting  various 
DBMS  studies  and  analyses  with  the  following 
objectives:  data  dependencies  —  to  achieve 
a  family  of  multilevel  secure  DBMS's; 
evaluation  —  to  investigate  the  evaluation 
ramifications  of  DBMS’s;  and  sanitization  — 
to  examine  the  downgrading  and  upgrading  of 
multi) evel  data  in  database  systems. 

J  study  is  being  conducted  of  the 
integrity  lock  technique,  which  cryptograph¬ 
ically  seals  information  stored  in  an 
automated  system,  with  the  objective  of 
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incorporating  this  technique  directly  into 
computer  architectures  supporting  multilevel 
secure  DBMS  operations.  And  finally,  the 
SAT  will  be  used  to  develop  a  trusted  DBMS 
application. 

Network  Security  focuses  on  the 
protection  of  data  while  it  is  being  trans¬ 
mitted  between  host  computers  and  users.  A 
data  communications  environment  has  been 
created  between  geographically  dispersed 
computers  that  includes  networks  of 
computers,  terminals  attached  to  computers 
that  are  attached  to  networks,  and  the 
internetting  of  multiple  and  various  combi¬ 
nations  of  these.  Current  computer 
networking  technology  has  concentrated  on 
providing  services  in  a  benign  environment, 
and  the  security  threats  to  these  networks 
have  been  largely  ignored.  While  literature 
abounds  with  examples  of  hackers  wreaking 
havoc  through  access  to  public  networks  and 
the  computers  connected  to  them,  hachers 
have  exploited  only  a  fraction  of  the 
vulnerabilities  that  exist.  Techniques  need 
to  be  developed  that  will  prevent  both 
passive  exploitation  (eavesdropping)  and 
active  exploitation  (alteration  of  messages 
or  message  routing) . 

To  reduce  these  vulnerabilities,  we 
have  initiated  research  in  the  development 
of  components,  high-level  applications  such 
as  distributed  processing,  multilevel  mail 
and  file  transfer,  modeling,  and  advanced 
architectures,  within  the  area  of  advanced 
architectures,  we  are  conducting  internet 
research,  device  authentication  studies,  and 
architectural  simulation.  The  challenges 
facing  us  in  the  network  security  field  are 
boundless.  We  hope  that  coordinating 
|  efforts  within  the  Federal  Government  and 

following  a  sound  R&D  program  will  enable  us 
to  work  with  industry  to  create  a  product 
line  of  network  security  systems  that  meet 
the  needs  of  the  Federal  Government  and  will 
be  available  in  the  marketplace. 

The  problems  of  introducing  computer 
security  into  the  Ad?,  programming  langauge 
are  being  investigated.  Ada  is  the  DoD- 
mandated  programming  language  for  mission- 
critical  systems.  We  are  developing 
verification  environments  to  be  integrated 
into  Ada  software  development  systems  as 
well  as  a  suite  of  secure  protocols  in  Ada 
to  demonstrate  how  to  marry  these  two 
technologies. 


throughout  the  system's  life  cycle, 
identifying  bottlenecks,  automating  tools 
to  simplify  the  evaluation  process, 
evaluating  the  effectiveness  of  safeguards, 
and  reducing  subjectivity  in  risk 
assessment.  We  are  involved  in  research  on 
intrusion  detection,  evaluation  tools  and 
techniques,  erasure  and  emergency 
destruction,  risk  management,  and  generic 
product  evaluation. 

Modeling  and  Verification  explores 
conceptual  solutions  to  computer  security 
problems  (modeling)  and  provides  assurance 
that  system  specifications  and/or  implemen¬ 
tations  are  consistent  with  the  model 
(verification).  Research  and  development 
in  modeling  and  verification  addresses  a 
critical  national  need  for  trusted  software 
and  hardware  systems  of  high  reliability. 

To  extend  the  state  of  the  art  in  security 
modeling  and  verification  approaches,  we 
have  embarked  on  five  research  endeavors: 
Ada  verification,  integrated  design  and 
verification  environment,  security 
modeling,  software  verification,  and 
hardware  and  firmware  verification.  Our 
ultimate  research  goal  is  to  verify  systems 
at  all  levels  of  design  and  implementation. 
In  this  regard,  we  note  the  similarity 
between  our  requirements  and  those  of  the 
Strategic  Defense  Initiative  (SDI).  We  are 
working  with  the  SDI  program  office  to 
explore  these  common  needB. 

We  believe  our  generic  Computer 
Security  R&D  Program  provides  the  solid 
framework  needed  to  convert  research 
breakthroughs  into  viable  products.  If  you 
in  industry,  as  the  practitioners  and 
managers  of  security  technologies,  think 
you  can  contribute  to  our  efforts,  we  would 
like  to  hear  from  you. 


Our  Aids  to  Evaluation  subprogram 
addresses  the  need  to  streamline  and  improve 
the  system  evaluation  process.  We  believe 
we  can  make  the  evaluation  process  more 
responsive  to  our  national  demand  for 
computer  security  by  providing  a  framework 
for  identifying  security  requirements 
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ABSTRACT 

There  are  various  hardware/software  architectures  that  will 
support  a  database  management  system  and  its  assorted 
applications.  Among  the  more  common  are  the  general  purpose 
operating  system/database  management  system  combination,  the 
backend  database  machine  implemented  in  hardware  or  software,  and 
the  distributed  database  management  system  on  several  hosts.  The 
distinction  between  the  security  responsibilities  of  the  database 
management  system  and  the  operating  system  is  not  well  defined. 
The  responsibilities  of  the  database  management  system  depend 
upon  the  security  policy  of  the  operating  system.  Both  database 
management  systems  and  operating  systems  can  provide  some  data 
security  to  user  applications  accessing  a  database.  The  question 
is  how  to  divide  the  security  controls  between  the  two. 

This  paper  discusses  the  various  system  configurations  which 
support  database  management  systems  and  the  security  tradeoffs 
inherent  in  each.  It  also  details  some  of  the  fundamental 
security  requirements  and  functions  of  the  database  management 
system,  and  the  operating  system  security  features  that  a 
database  management  system  could  take  advantage  of  to  enhance  its 
own  security  features.  The  paper  concludes  with  a  summary  of  the 
author's  current  thought  on  secure  database  management 
architectures  and  their  potential  for  near  term  implementation. 


GENERAL  ARCHITECTURE  OVERVIEW 

Current  operating  systems  technology 
makes  a  case  for  thre  i  generic  system 
architecture  types  that  can  support  a 
database  management  system.  These  types  are: 

a  general  purpose  operating  system 

a  database  machine  environment 

a  distributed  processing  system. 

General  Purpose  Operating  System 

The  general  purpose  operating  system 
environment  (figure  1)  provides  a  series  of 
general  services  to  a  wide  variety  of  users 
and  their  applications.  These  services 
include  a  file  system,  input/output 
management,  user  authorization  and 
authentication,  and  recovery  procedures. 

This  class  of  system  can  best  be  categorized 
by  products  such  as  Ur.ix*-m3- ,  VMS1-1112 ,  MVStln3 , 
and  other  widely  used  time  sharing  systems. 

1  Unix  is  a  registered  Trademark  of  Bell 
Laboratories 

2  VMS  is  a  registered  Trademark  of  the 
Digital  Equipment  Corporation. 

3  MVS  is  a  registered  Trademark  of  the 
International  Business  Machines  Corp. 


Within  the  general  purpose  operating 
system  environment,  there  are  two  basic  types 
of  security  policies  enforced:  those  that 
provide  some  degree  of  discretionary  access 
control,  and  those  that  provide  mandatory 
access  controls.  The  security  controls  of 
most  general  purpose  operating  systems  are 
usually  only  of  a  discretionary  nature;  they 
do  not  protect  the  user  from  the  potential 
compromise  of  his  data  by  his  associates. 

For  example,  if  a  user  gives  read  access  to 
his  file  to  another  user,  there  is  no 
mechanism  to  prevent  the  second  user  from 
copying  the  file  and  granting  access  to  other 
users. 

Discretionary  access  control  is  defined 
by  the  Trusted  Computer  Systems  Evaluation 
Criteria  (The  Criteria)  (1)  as  providing  a 
means  of  restricting  access  to  object  based 
on  the  identity  of  subjects  and/or  groups  to 
which  they  belong.  According  to  the 
Criteria,  the  controls  are  discretionary  in 
the  sense  that  a  subject  (user)  with  certain 
access  permission  is  capable  of  passing  that 
permission  on  to  any  other  subject.  In  the 
context  of  this  discussion,  systems  meeting 
the  requirements  for  the  C2 -level  of  the 
Criteria  are  defined  as  discretionary  access 
control  computer  systems.  For  example,  a 
user  with  read/write  access  to  a  file  can 
grant  read/write  access  to  that  file  to 
another  user. 
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A  secure  database  management  system 
existing  on  an  operating  system  with  good 
discretionary  access  controls  affords  the 
user  the  ability  to  control  authorized  access 
to  the  database  on  a  per  user  basis.  The 
operating  system  support  of  discretionary 
access  control  provides  a  higher  degree  of 
confidence  in  this  protection  because  it  is 
enforced  not  only  by  the  database  management 
system  but  also  by  the  operating  system's 
discretionary  access  control  policy.  This 
type  of  security  is  also  most  easily 
incorporated  into  existing  products  in  both 
the  operating  systems  and  database  management 
systems  commercially  available  today.  The 
general  purpose  operating  system  can  also 
provide  the  database  management  system  with 
authentication  and  authorization  mechanisms. 
For  example,  the  password  generation  and  one¬ 
way  encryption  features  of  system  login  could 
also  be  used  if  a  database  were  password 
protected. 

Relying  only  upon  a  discretionary 
security  policy  to  provide  a  foundation  for  a 
secure  database  management  system  may  have 
B3rious  disadvantages.  Most  currently 
available  systems  with  a  discretionary  access 
control  policy  implemented  can  be  easily 
circumvented.  This  allows  a  user  to  bypass 
the  database  management  system's  security 
controls  and  access  any  database  directly 
from  the  operating  system. .  such  an  attack 
would  allow  one  ctaracase  files  to  be  read 
with  conventional  file  access  techniques 
supported  by  any  programming  language.  These 
systems  are  currently  vulnerable  to  Trojan 
Horse  penetration  attacks  because  the  user 
doeu  not  maintain  complete  control  over  the 
access  rights  to  a  file.  For  example,  if  a 
user  runs  an  untrusted  program,  once  this 
program  grants  read  privileges  to  a  malicious 
user,  the  second  user  cannot  be  prevented 
from  granting  read  privileges  to  yet  another 
user,  indeed,  the  entire  user  population 
could  eventually  gain  read  access  to  the 
file,  thereby  defeating  the  purpose  of 
discretionary  access  control. 

Discretionary  access  control  operating 
systems  may  not  have  an  automatic  label 
enforcement  mechanism  to  label  data  and  files 
with  the  appropriate  sensitivity  marking. 
While  these  operating  systems  do  provide  some 
protection  for  the  database  management 
system,  they  do  not  promote  a  high  degree  of 
confidence  in  their  controls,  and,  in  effect, 
permit  the  user  to  define  trust  and  thereby 
grant  other  users  the  ability  to  potentially 
compromise  the' data.  Future  implementations 
of  discretionary  access  controls  may  provide 
better  protection  and  enforce  different 
security  policies  which  may  better  address 
some  of  the  shortcomings  of  current 
discretionary  access  control  implementations. 

General  purpose  operating  systems  with 
mandatory  access  control  security  policies 
implemented  are  usually  multilevel  secure 
systems.  Mandatory  access  control  is  defined 
by  the  Criteria  as  a  means  of  restricting 
access  to  objects  based  on  the  sensitivity 
(as  represented  by  a  label)  of  the 
information  contained  in  the  objects  and  the 
formal  author iz at J.on  or  clearance  of  subjects 
to  access  information  of  such  sensitivity. 
This  means  that  users  are  protected  from  each 
other  by  the  reference  monitor  using  their 


sensitivity  levels,  which  are  used  to  label 
their  processes,  and  by  the  labels  attached 
to  their  files.  Manipulation  of  file 
information  is  based  on  a  composite  of  the 
mandatory  access  control  and  the 
discretionary  access  control  labels.  For 
example,  a  user  cannot  exist  at  the  top 
secret  level  and  modify  an  unclassified  file, 
even  if  ha  has  discretionary  write  access  to 
the  file.  Such  a  "write-down"  could  violate 
the  mandatory  security  policy  of  the  system. 
Multilevel  systems  are  relatively  uncommon, 
the  most  notable  being  Honeywell's  Multics 
system  and  the  SCOMP  (2) . 

A  multilevel  computer  system  can  easily 
be  thought  of  as  a  series  of  single  level 
computer  systems  residing  on  the  same 
hardware  base  and  executing  the  same  copy  of 
the  operating  system  at  the  same  time  with 
different  processes  at  various  levels 
cooperating  with  each  other  under  the  control 
of  the  operating  system  (3) .  Operating 
systems  which  enforce  mandatory  access 
control  policies  afford  the  database 
management  system  all  of  the  advantages  of 
discretionary  access  controls,  but  also  add 
further  security  controls.  Labeling,  for 
example,  is  enforced  on  all  objects  (files 
and  directories)  known  to  the  operating 
system. 

Most  operating  systems  with  mandatory 
access  controls  are  implemented  with  a 
security  kernel  architecture  which  enforces 
the  system  security  policy  on  all  access  and 
authorization  commands.  The  security  kernel 
operates  through  a  trusted  path  which  allows 
the  user  to  communicate  directly  to  the 
trusted  computing  base  during  these 
operations.  There  are  no  such  trusted  paths 
or  security  kernels  required  in  discretionary 
access  control  operating  systems  below  the 
B2-level  of  the  Criteria.  The  possibility  of 
a  system-wide  Trojan  Horse  attack  is  also 
greatly  minimized  in  a  mandatory  access 
control  system  because  data  is  partitioned 
according  to  a  user's  authorization  rights. 

A  Trojun  Horse  attack  would  be  limited  to  at 
most  one  sensitivity  level  of  the  system 
since  objects  are  labeled  by  level  and  are 
not  changeable  by  an  untrusted  process.  This 
holds  true  only  for  disclosure  of 
information,  not  data  integrity.  The 
existence  of  the  trusted  path  also  minimizes 
the  risk  of  spoofing  penetration  because  of 
the  direct  communication  required  between  the 
user  and  the  security  kernel.  All  of  these 
features  laad  to  a  higher  degree  of  assurance 
that  the  security  policy  is  enforced.  That  " 
is,  the  user  is  protected  against  other  users 
and  maintains  control  over  his  data. 

Mandatory  security  access  controls  do  not 
solve  all  operating  system  security  problems. 
The  probability  of  covert  storage  and  timing 
channels  is  greatly  increased  in  comparison 
to  discretionary  access  control  systems  by 
virtue  of  the  fact  that  information  must 
somehow  be  communicated  between  the  levels 
for  the  operating  system  to  function  (4) . 

Such  channels  offer  a  ready  method  of  system 
exploitation  if  two  or  more  users  coordinate 
in  an  attack  with  cooperating  processes. 

Current  implementations  of  security 
policy  models  do  not  provide  sufficient 
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support  for  finer  levels  of  label 
granularity,  Sansitivity  labels  may  net  be 
automatically  enforced  to  the  level  of 
granularity  required  for  them  to  be  used 
effectively  in  database  management  systems. 

For  example,  the  operating  system  may  support 
mandatory  access  control  on  objects  down  to 
the  file  level.  Labeling  on  tuples  or 
relations  within  a  file,  however,  would  be 
the  domain  of  the  database  management  system. 
Thera  may  also  be  severe  performance 
penalties  in  that  the  general  purpose 
operating  system  kernel  and  the  database 
management  system  kernel  have  to  communicate 
with  each  other  to  determine  division  of 
labor  and  perform  file  and  directory 
manipulation.  Some  degree  of  confidence 
would  also  have  to  be  assigned  to  the 
database  management  system  in  order  for  it  to 
support  its  own  security  policy. 

No  database  management  system  has  yet 
been  implemented  that  takes  advantage  of  the 
multilevel  features  of  general  purpose 
mandatory  access  control  operating  systems. 

If  such  a  database  management  system  did 
exist,  it  could  afford  greater  protection  to 
the  user  and  minimize  the  number  of 
penetration  techniques  that  could  be  used  to 
exploit  its  flaws  to  a  more  finite  set. 

Database  Machines 

Backend  database  machines  (figure  2) 
effectively  remove  the  responsibilities  for 
data  access  methods  from  the  general  purpose 
operating  system.  The  backend  database 
machine  approach  has  been  discussed  for 
several  years,  but  has  become  commercially 
available  only  within  the  last  five  years. 
This  architecture  is  implemented  in  two  basic 
configurations,  the  hardware  and  software 
backend  database  machines. 

The  hardware  backend  can  be  defined  as  a 
series  of  one  or  more  processors  which 
implement  a  particular  database  management 
system  or  type  of  database  management  system 
in  custom  firmware  (5) .  Those  systems  have 
been  developed  with  two  basic  architectures; 
the  standalone,  host  independent  database 
machine  and  the  intelligent  disk  controller. 
The  host  independent  database  machine  (figure 
3)  encompasses  all  features  of  a  database 
management  system  through  a  combination  of 
its  hardware  and  its  operating  system.  In 
this  architecture,  the  database  machine  must 
take  all  responsibilities  for  its  own 
security  and  does  not  have  the  security 
protection  of  a  general  purpose  operating 
system.  The  system  can  do  all  query 
processing  and  data  reporting  as  if  it  were  a 
general  purpose  operating  system  with  the 
database  management  software  in  execution. 

Or  the  system  can  take  requests  passed  to  it 
from  other  frontend  general  purpose  hosts  and 
pass  the  results  back  to  the  requesting 
process. 

The  primary  security  advantage  gained  in 
this  approach  is  the  physical  separation  of 
the  database  management  system  from  the 
frontend  computer  systems.  This  permits  the 
database  management  system  to  control  all 
access  to  the  databases.  The  database 
machine  has  all  security  responsibilities  for 
its  storage  devices  and  may  implement  its  own 


protection  mechanisms.  The  only  dependency 
between  the  host  independent  database  machine 
and  the  host  is  that  of  a  channel  to  pass 
information  back  to  the  host  and 
authentication  and  query  information  to  the 
database  machine.  As  an  additional  security 
measure,  the  database  machine  could  require 
its  own  user  authentication  mechanism. 

The  independent  database  machine  approach 
also  implies  that  the  database  management 
system  used  on  the  database  machine  will  only 
have  to  be  secured  once,  with  minimal  changes 
to  host-resident  front-end  software,  as 
opposed  to  securing  multiple  versions  of  the 
database  management  system  on  a  per  host 
basis.  Such  a  system  could  also  enhance 
system  performance  on  the  frontend  systems 
because  all  the  security  controls  for  the 
database  management  system  are  done  on  the 
backend  database  machine.  This  approach  also 
allows  hosts  trusted  at  different  sensitivity 
levels  to  communicate  with  the  backend 
database  machine,  which,  in  turn,  would 
ensure  that  they  are  permitted  to  access  data 
only  at  their  authorized  sensitivity  level. 
This  feature  provides  data  segregation 
without  replication  of  complete  computer 
systems.  It  should  bo  noted,  however,  that 
the  database  machine  would  have  to  be  trusted 
at  least  to  the  highest  level  of  trust  of  the 
attached  hosts.  For  example,  a  database 
machine  connected  to  C2  and  B3  level  hosts 
would  have  to  be  trusted  to  at  least  the  B3 
level. 

The  backend  host  independent  database 
machine  is  susceptible  to  covert  signalling 
channels  between  cooperating  processes.  A 
trusted  path  between  the  database  machine  and 
host  must  exist  to  prevent  Trojan  Horse 
attacks  and  spoofing  of  the  database  machine. 
The  mechanism  for  trusting  the  database 
machine  is  evident;  how  to  build  a  trusted 
channel  between  the  two  systems  is  a  harder 
problem.  Encryption  techniques  alone  do  not 
appear  to  provide  adequate  protection,  other 
safeguards  must  be  incorporated  to  secure  the 
channel.  Of  course,  thB  database  machine 
architecture  was  designed  to  enforce  security 
since  retrofit  of  the  mechanisms  could  result 
in  a  major  restructuring  of  the  system 
architecture  to  remove  host  dependant 
features. 

The  host  dependent  backend  database 
machine  (figure  4)  can  be  viewed  as  an 
intelligent  disk  controller.  This  approach 
to  the  backend  database  machine  implements 
and  executes  the  high-level  data  manipulation 
language  on  the  frontend  host  and  requires  a 
substantial  amount  of  host-resident  software 
to  validate  queries  before  they  are  sent  to 
the  controller  for  processing.  The 
controller  executes  the  most  efficient 
implementation  of  the  query  to  collect  the 
data  requested,  but  does  not  have  the 
wherewithal  to  do  very  much  with  it  except 
pass  It  back  to  the  requesting  process.  The 
security  assurances  afforded  by  this 
architecture  are  those  associated  with  a 
general  purpose  operating  system's  security 
policy.  Current  implementations  of  security 
constraints  on  these  systems  reflect  the 
security  policy  of  the  database  management 
system  working  in  the  frontend  and  are 
usually  discretionary  access  control 
mechanisms . 


219 


Th8  primary  advantage  to  this  approach  is 
in  the  area  of  system  performance.  Response 
time  can  be  dramatically  decreased  by  using 
efficient  search  algorithms  implemented  in 
the  backend  controller.  It  is  possible  that 
some  discretionary  and  mandatory  access 
control  could  be  done  by  the  intelligent 
controller  as  part  of  its  query  processing. 
Once  again,  the  intelligent  controller  must 
support  the  highest  host  level  of  trust  if  it 
does  any  security  enforcement  tasks.  The 
dependence  on  the  host  system  for  most  of  the 
security  policy  enforcement  in  this  approach 
can  also  become  a  liability  if  the  security 
policy  of  the  host  system  does  not  afford 
user  applications  adequate  protection.  The 
host  dependent  backend  machine  also  must 
depend  on  the  host  system  for  authentication 
and  user  identification  functions.  Since  it 
has  no  direct  contact  with  the  user,  it 
cannot  query  him  for  additional  authorization 
and  authentication  information  and  must  rely 
on  the  mechanisms  in  place  on  the  host 
system.  The  backend  host  dependent  database 
machine  must  be  reconfigured  for  each  host 
operating  system.  That  is,  the  front-end 
software,  to  do  all  necessary  host  functions, 
must  be  modified  on  a  per  operating  system 
basis.  A  trusted  path  between  the  disk 
controller  and  the  host  must  also  exist  to 
prevent  penetration  attacks  and  spoofing  that 
would  circumvent  the  system  security 
mechanisms. 

In  the  software  backend  database 
management  system  (figure  5),  the  specialized 
retrieval  and  parallel  processing 
architectures  of  the  hardware  backend 
database  machines  are  simulated  by  special 
software  instead.  This  backend  may  exist  on 
the  general  purpose  computer  system.  It  is 
similar  to  the  intelligent  disk  controller. 
Once  again,  the  security  policy  of  the 
software  backend  approach  mirrors  the 
security  policy  of  the  particular  database 
management  system  in  use  on  the  system.  The 
principal  advantage  of  this  approach  is  the 
enhanced  performance  capabilities. 
Additionally,  all  of  the  resources  of  the 
operating  system  are  available  to  the 
database  management  system.  As  a  result,  the 
security  policy  of  the  operating  system  can 
be  readily  incorporated  into  the  database 
management  system.  Because  of  the 
implementation  approach  used  hare,  it  may 
also  be  possible  to  permit  the  database 
management  system  to  enforce  an  alternative 
security  policy  that  could  coexist  with  the 
operating  system  security  policy.  The  heavy 
reliance  of  this  type  of  backend  on  the 
operating  system  can  also  be  considered  a 
major  liability.  Exporting  this  architecture 
to  other  operating  systems  and  enforcing  the 
proper  function  of  the  security  mechanisms  on 
other  operating  systems  are  the  primary 
disadvantages  with  this  architecture. 

There  is  also  a  multiprocessor 
multibackend  version  of  this  architecture 
(figure  6)  that  utilizes  a  number  of 
identical  backends  each  using  a  copy  of  the 
same  software.  The  single  software  system  as 
well  as  the  multibackend  software  system  does 
not  involve  modification  of  the  system's 
hardware;  rather  they  rely  on  innovative 
software  techniques  to  do  their  processing. 
This  approach  permits  a  security  kernel  to 
exist  in  the  traffic  controller  (a  particular 


software  program)  that  routes  queries  to  each 
backend  according  to  their  sensitivity  level. 
Performance  may  also  be  improved  because 
multiple  backends  can  be  processing  portions 
of  the  same  query  in  parallel  and  perform 
some  of  the  required  security  enforcement. 
Physical  segregation  of  the  data  can  also  be 
enforced  by  storing  only  data  with  a 
particular  sensitivity  label  on  a  given 
backend.  The  system  also  complicates  of 
configuration  management  control  because 
there  must  be  multiple  copies  of  the  software 
running  on  the  system  to  access  data  on  each 
controller.  The  problems  associated  with 
this  approach  are  those  of  the  single 
software  backend  architecture,  but  they  are 
compounded  because  multiple  backends  exist. 
Additionally,  each  backend  consults  with  the 
other  backends  occasionally  in  the  course  of 
query  processing,  thereby  creating  a 
potentially  very  large  covert  channel  between 
the  backends. 

Distributed  Database  Management 

The  third  generic  architecture,  a 
distributed  database  management  system,  is  a 
relatively  new  technology  and  poses  new 
security  problems.  Date  defines  a 
distributed  database  management  system  as  any 
system  involving  multiple  sites  connected 
together  into  some  kind  of  communications 
network,  in  which  a  user  (end  user  or 
application  programmer)  at  any  site,  can 
access  data  stored  at  any  site  (6) .  There 
are  two  basic  types  of  distributed  systems: 
homogeneous  and  heterogeneous.  The 
homogeneous  distributed  system  is  one  in 
which  the  same  version  of  the  database 
management  system  software  and  possibly  the 
same  operating  system  is  running  at  each 
site.  A  heterogeneous  system  may  have 
different  database  management  systems, 
operating  systems,  and  processors  present  at 
each  site.  From  a  security  standpoint,  the 
distributed  case  becomes  very  complicated 
because  not  only  does  database  management 
security  have  to  be  considered,  but  operating 
system  security  and  network  security  features 
must  also  be  taken  into  account.  Because 
this  area  is  so  unknown,  it  is  difficult  to 
determine  the  combination  of  mandatory  and 
discretionary  access  controls  that  would  be 
needed  to  secure  a  distributed  database 
management  system.  Distributed  and 
decentralized  database  control  is  a  very 
important  and  difficult  research  area. 
Processing  decisions  in  distributed  database 
management  system  can  be  based  on  incomplete 
and  inaccurate  information  when  information 
from  other  hosts  is  unavailable.  Formulation 
of  the  global  security  policy  for  a 
distributed  database  management  system  is  not 
presently  well  understood. 

If  a  security  policy  could  be  formulated 
for  a  distributed  database  management  system, 
it  would  be  most  advantageous.  Data  could  be 
logically  and  possibly  geographically 
distributed  among  a  variety  of  hosts,  each  of 
which  could  control  his  own  sensitive  data 
and  authenticate  queries  from  the  other  nodes 
on  the  system.  The  additional  processors  of 
a  distributed  system  could  improve  system 
performance  in  a  very  large  database 
environment  with  massive  processing 
requirements.  Smaller  database  applica 
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would  probably  experience  a  degradation  in 
performance  because  of  the  overhead  of 
transporting  data  across  the  nodes.  The 
possibility  of  data  replication  in  the 
distributed  environment  also  provides  a 
method  for  trusted  recovery.  Xf  a  node  on 
the  distributed  system  crashes,  it  could 
conceivably  recover  and  return  to  service  by 
copying  its  databases  from  another  node. 
Also,  the  removal  of  a  node  from  service 
would  not  necessarily  impair  the  overall 
security  integrity  of  the  distributed  system 
because  the  other  nodes  would  remain  intact. 


Distributed  systems  also  raise  many  new 
and  potentially  serious  security  concerns. 
Perhaps  the  largest  security  loophole  is 
concurrency  control  and  database 
modification.  Locking  in  the  distributed 
environment  has  to  be  done  very  carefully  to 
avoid  denial  of  service  to  nonlocal  nodes 
which  may  be  doing  retrievals  against  a 
database  while  another  user  is  doing  updates. 
Maintenance  of  journals  in  the  distributed 
case  is  also  difficult  and  must  deal  with 
many  of  the  same  considerations  as  the 
concurrency  control  problem.  The  possibility 
of  compromise  increases  when  data  is  accessed 
over  a  distributed  system,  simply  because  the 
user  now  has  access  to  more  than  one  computer 
system  available  for  penetration  attempts. 
Denial  of  service  attacks  are  harder  to 
detect  and  differentiate  from  a  normal 
database  lock  on  another  node  or  the  time 

spent  in  network  traffic.  The  preservation 
of  label  integrity  and  label  recognition 
across  the  nodes  of  the  distributed  system 
must  also  be  addressed.  It  is  also  possible 
that  the  problems  associated  with  data 
inference  and  aggregation  will  become 
increasingly  more  complex  as  additional  nodes 
are  added  to  a  distributed  system.  Xn 
addition  to  all  of  these  problems,  the  issues 
of  network  security  must  be  considered  in  the 
development  of  the  distributed  database 
management  system. 


Within  the  framework  of  these  general 
architectures,  there  are  certain  dependencies 
between  the  database  management  system  and 
the  operating  system  that  apply  in  all  oases, 
stonebraker  outlined  these  dependencies  in 
1981  and  concluded  that  operating  systems 
were  inefficient  and  not  designed  to 
accommodate  database  management  systems,  but 
did  not  address  the  security  considerations 
involved  (7) .  Even  if  the  database 
management  system  provides  all  of  its  own 
support  in  a  backend  database  machine 
environment,  the  functions  generally 
performed  by  a  multi-user  operating  system 
are  performed  in  the  database  machine  kernel 
and  hardware.  What  are  these  functional 
dependencies,  and  what  implications  do  they 
have  for  a  secura  database  architecture? 


Perhaps  the  largest  functional  dependency 
is  that  of  file  management.  Most  database 
management  systems  use  the  system  file 


handling  routines  to  do  some  input/output 
processing.  Most  database  management  systems 
use  the  file  system  to  implement  relations, 
one  relation  or  one  database  per  file.  Over 
this  file,  the  data  views  or  subschemas  are 
superimposed.  The  operating  system  is 
responsible  for  opening,  closing,  update,  and 
read  operations  on  the  relation  or  database. 
Additionally,  the  operating  system  opens  and 
closes  the  data  dictionary  which  enforces  the 
database  structure  and  subschema  hierarchy  on 
the  user's  process. 

Beyond  these  basic  functions,  the  file 
management  system  may  also  be  relied  upon  to 
perform  access  control  checking  on  the 
relations  or  databases  being  used.  Whether 
this  takes  the  form  of  mandatory  and/or 
discretionary  access  control  is  a  direct 
function  of  the  security  policy  implemented 
by  the  operating  system.  Xn  the  case  of  the 
general  purpose  operating  system, 
discretionary  access  control  on  relations  or 
databases  can  be  readily  enforced  since  they 
are  already  incorporated  into  some  commercial 
products.  Operating  system  discretionary 
access  controls  reinforce  these  existing 
mechanisms,  but  are  dependent  upon  the 
storage  structures  of  the  database  management 
system.  Xf  the  user  does  not  have  write 
access  to  the  file,  for  example,  he  cannot 
update  a  relation  or  database.  If  the  user 
does  not  have  add  privileges,  he  may  be  able 
to  update  existing  tuples  but  cannot  create 
new  tuples.  Xn  mandatory  access  control,  the 
database  management  system  also  depends  upon 
the  operating  system  to  validate  the  user  and 
file  authorization  labels  to  ensure  that  the 
operation  requested  does  not  conflict  with 
the  system  security  policy.  Reliance  on 
system  file  management  routines  does  present 
solutions  to  several  areas  of  security 
concern.  However,  file  input/output  is  not 
usually  the  most  efficient  access  method  for 
database  management  and  operating  system  file 
management  routines  may  be  bypassed.  To 
optimize  database  performance,  smaller  buffsr 
sizes  and  blocks  of  data  are  preferred  to 
manipulation  of  file-sized  structures.  This 
also  leads  to  the  issue  of  object  label 
granularity,  which  is  discussed  elsewhere  in 
this  paper. 

A  special  area  of  file  managment  within 
the  database  management  environment  is  that 
of  recovery  services  and  auditing.  Most 
database  management  systems  that  keep 
journals  or  transaction  logs  exist  in  a 
single  level  environment.  Those  few  that 
have  triad  to  exist  in  a  multilevel  system 
have  done  so  by  maintaining  separate  journals 
at  each  level,  makinq  recovery  procedures 
complex.  The  dilemma  with  journals  is  that 
they  must  be  kept,  which  implies  they  have  to 
be  written  to  by  each  user.  However,  users 
should  not  be  able  to  read  what  they  have 
written  to  the  journal,  and  its  existence 
should  be  transparent  to  the  user.  This 
applies  in  most  oases.  In  the  event  the  user 
cannot  commit  a  transaction  to  the  database, 
however,  the  database  management  system 
should  be  able  to  initiate  a  rollback  on  the 
user's  behalf  and  restart  the  transaction. 

The  database  management  system  should  also  be 
able  to  examine  a  database  for  damage  in  the 
event  the  system  should  crash  and  to  restore 
the  database  management  system  and  its 
accompanying  databases  to  a  consistent  state. 
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Closely  related  to  recovery  and  file 
management  is  audit  maintenance  and  control. 
Many  of  the  same  problems  inherent  in 
transaction  journals  also  exist  in  audit 
files.  Indeed,  in  most  systems,  they  are  one 
and  the  same.  However,  the  database 
management  system  can,  and  often  does,  use 
the  system  audit  facilities  to  create  a  bare 
bones  audit  of  its  own.  This  type  of  audit 
contains  only  information  related  to  tuples 
that  updated  the  appearance  of  the  database. 
Those  tuples  which  are  read  out  of  the 
database  for  a  report,  for  example,  are  not 
included  in  this  type  of  audit.  An  audit 
such  as  this  would  be  highly  useful  in 
recovery,  but  would  not  be  very  useful  if  the 
database  administrator  or  system  security 
officer  was  trying  to  determine  if  an 
inference  or  penetration  attack  was  underway. 
Such  an  attack  would  not  have  to  modify  the 
data  but  only  collect  it.  The  problems  of 
enforcing  the  appropriate  access  controls 
also  continue  to  exist  in  audit  functions  and 
files  as  well. 

Additionally,  the  question  of  what  the 
database  treats  as  a  subject  and  what  the 
database  treats  as  an  object  for  audit 
purposes  must  be  answered.  If  the  object  for 
an  audit  is  defined  as  each  individual 
attribute  in  a  database,  the  audit  files  will 
quickly  become  very  unwieldy.  If  the  object 
is  the  relation,  on  the  other  hand,  not 
enough  information  will  be  available  for  a 
meaningful  audit  trail  to  exist.  By  the  same 
token,  it  may  make  more  sense  in  the  database 
environment  to  audit  by  object  than  by 
subject.  That  is,  the  data  accessed  should 
be  audited  as  opposed  to  the  user  or  accessor 
of  that  data.  In  database  management 
systems,  one  is  more  interested  in  access 
attempts  on  a  particular  sensitive  data  item 
than  in  all  actions  done  by  a  particular 
user.  Additionally,  if  the  audit  is 
conducted  on  a  per  attribute  basis,  auditing 
on  a  subject  level  could  result  in  very  large 
audit  logs.  These  areas  must  be  addressed  if 
a  database  management  system  will  manage  data 
securely . 

Label  Granularity 

The  issue  of  label  granularity  is  another 
area  in  which  there  are  functional 
dependencies  between  the  operating  system  and 
the  database  management  system.  Most 
operating  systems  only  support  labeling  at 
the  file  and  directory  (a  logical  collection 
of  files)  level.  They  do  not  support  the 
labeling  of  entities  smaller  than  a  file. 
Therefore,  most  database  management  systems 
have  to  maintain  their  own  labels  and  be 
responsible  for  their  integrity.  Database 
management  systems  cannot  use  the  system 
level  mandatory  and  discretionary  access 
control  mechanisms  to  enforce  access  rights 
to  any  finer  level  of  granularity.  In  fact, 
the  database  management  syst-sm  will  probably 
have  to  violate  the  operating  system  security 
policy  to  manipulate  smaller  multilevel 
objects.  This,  in  turn,  causes  concurrency 
control  problems  because  looking  can  only  be 
accomplished  when  access  control  can  be 
enforced  on  the  database.  Additionally,  the 
question  of  whether  or  not  to  trust  labels 
which  are  not  enforced  by  the  operating 
system  security  kernel  must  be  addressed. 


Another  issue  In  this  area  is  the  interface 
between  the  database  management  system’s 
labeling  techniques  and  the  operating 
system's  labeling  technique.  In  this  case, 
should  labels  attached  by  the  database 
management  system  be  considered  valid  by  the 
operating  system?  Current  technology  may  not 
permit  a  lower  level  of  labeling  without  a 
substantial  performance  penalty,  rendering  a 
database  management  system  unusable  in  real- 
time  user  response  time  applications. 

Memory  Management 

The  database  management  system  may  rely 
on  the  operating  system  to  perform  memory 
management  on  its  behalf  as  well.  In  this 
area  the  largest  functional  dependency  is 
that  of  object  reuse.  The  database 
management  system  uses  those  pages  of  memory 
the  system  allocates  to  it  and  leaves  the 
system  to  perform  object  reuse  functions  on 
those  pages.  For  example,  if  the  page  was 
not  modified,  it  will  not  be  written  back  out 
to  disk.  If  the  page  was  modified,  it  must 
be  checked  to  ensure  that  the  labels 
associated  with  that  page  aro  still  valid 
before  it  is  put  back  on  the  disk. 
Additionally,  before  the  page  frame  is 
reused,  it  must  be  overwritten  to  prevent 
recovery  of  data  by  the  next  unauthorized 
user.  Soma  operating  systems  leave  object 
reuse/data  remanence  up  to  the  particular 
application.  Others  perform  the  funotion  as 
a  matter  of  course.  The  database  management 
system  should  make  no  assumption  as  to  what 
services  the  operating  system  provides  for  it 
in  this  regard,  but  could  take  advantage  of 
operating  system  services  if  they  are 
available. 
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The  question  of  denial  of  servioe  is  also 
tied  to  a  database  management  system’s 
dependencies  on  the  operating  system.  For 
example,  if  the  operating  system  has  decided 
to  swap  out  a  process  that  has  the  database 
locked  for  update,  the  competing  processes 
which  may  wish  to  use  that  database  are 
denied  service  until  the  swapped  process  is 
brought  back  in  to  finish  its  execution. 

With  the  possible  exception  of  custom 
database  machine  environments,  the  case  of 
denial  of  service  in  database  management  is 
complicated  not  only  by  the  database 
management  system's  own  locking  algorithms, 
but  by  the  operating  system' s  process 
scheduler  software.  Synchronization  in  the 
interaction  of  the  database  management  system 
and  the  scheduler  may  make  an  database 
management  system  too  dependent  on  a 
particular  operating  system  to  make  it 
portable  to  other  operating  systems. 

Ifltsrgupt.JjanAUna 

Connected  to  the  memory  management 
dependencies  are  the  database  management 
system's  dependencies  on  the  operating  system 
in  the  area  of  interrupt  handling.  By 
necessity,  database  management  systems 
generate  interrupt  requests  to  the  operating 
system  to  perform  various  operations  such  as 
requests  for  files,  input/output  handling, 
and  process  wakeup  and  block  messages.  The 
operating  system,  in  turn,  executes  these 
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requests  and  generates  the  appropriate 
interrupts,  which,  in  turn,  may  be  audited  by 
the  operating  system  as  needed.  The 
interrupt  interaction  between  the  database 
management  system  and  the  operating  system 
offers  a  wide  range  of  opportunities  for 
covert  channel  exploitation.  For  example,  a 
user  could  have  a  database  locked  for 
exclusive  update  and  then  trigger  an 
interrupt  that  would  suspend  his  process. 
Another  user  would  not  be  able  to  access  the 
database  while  the  lock  table  showed  that  the 
other  user  had  it  exclusively  locked.  In 
this  case,  the  lock  table  could  be  used  as  a 
covert  signalling  channel  between  the  two 
user's  processes.  Unfortunately,  with  the 
possible  exception  of  the  database  machine 
case,  there  is  little  that  can  be  dona  to 
minimize  the  need  for  such  communication 
during  interrupt  processing,  although  the 
implementation  of  interrupt  handling  in  a 
secure  operating  system  may  afford  sufficient 
security  features  to  minimize  the  opportunity 
for  covert  channel  exploitation  through  the 
interrupt  processing  facilities. 

Interrupt  processing  raises  the  question 
of  the  concept  of  the  trusted  path  and 
trusted  processes.  Certain  functions  of  an 
operating  system,  for  example,  the 
input/output  controller  and  the  mail  system, 
have  the  ability  to  bypass  system  standard 
access  control  policies.  These  processes  are 
known  as  trusted  processes,  and  their  ability 
to  communicate  with  the  security  kernel 
requires  a  "trusted  path"  to  the  security 
primitives.  Obviously,  labels  have  to  be 
enforced  from  the  user  perspective,  but 
certain  operations,  such  as  label 
manipulation  and  modification,  hove  to  be 
considered  trusted  processes.  Their  use 
should  be  permitted  only  by  database 
administrators  or  system  security  officers, 
and,  even  then,  heavily  audited.  Obviously, 
for  regular  functions,  the  trusted  process 
haa  to  exist  as  a  standard  feature  and  be 
used  rather  frequently.  In  these  cases,  the 
trusted  process  resides  at  the  highest 
security  level  accessible  to  the  user.  Whan 
a  request  that  requires  trusted  intervention 
is  made,  the  trusted  process  filters  the 
request  to  the  appropriate  files,  and 
consolidates  the  returned  responses  before 
passing  them  back  to  the  user  at  the 
appropriate  level.  Once  again,  there  is  a 
substantial  possibility  of  large  covert 
channels,  but  extensive  audit  files  and 
system  security  controls  on  user  processes 
help  to  minimize  the  associated  .risks. 


Related  \  o  trusted  processes  is  the  area 
of  authentication  and  authorization 
techniques.  The  database  management  system 
may  not  require  that  each  database  is 
password  protected.  It  may  use  the  system's 
authorization  control  mechanism  to  enforce 
access  control  on  the  database.  In  turn,  use 
of  the  authorization  control  implies  that  the 
database  management  system  is  willing  to 
accept  the  authentication  mechanisms  of  the 
operating  system  as  well.  With  such  a 
scenario,  the  user  logs  into  the  system, 
which  in  turn  authenticates  his  identity  and 
validates  his  authorization  levels  for  the 
existence  of  his  process.  The  database 
management  system,  in  turn,  uses  the  user's 


authenticated  information  to  determine  his 
access  rights  to  the  data.  It  is  also 
possible  for  the  database  management  system 
to  take  advantage  of  the  operating  system's 
enforcement  mechanisms  for  mandatory  and 
discretionary  access  control  through  the 
authentication/authorization  mechanism.  That 
is,  if  the  user  is  not  at  the  appropriate 
level  in  a  multilevel  system  and  attempts  to 
access  a  database  in  violation  of  the  system 
security  policy,  the  operating  system  access 

mechanism  may  prevent  this  occurrence  and 
generate  an  interrupt,  which  must  be 
intercepted  and  interpreted  by  the  database 
management  system.  The  same  scenario  aould 
also  be  used  in  the  case  of  discretionary 
access  control  where  the  user  attempts  to 
update  a  relation  he  is  only  permitted  to 
read.  The  complexity  of  the  interface 
between  the  database  management  system  and 
the  operating  system  in  this  area  could  be 
reduced  if  the  database  management  system  did 
its  own  validation  on  access  requests  prior 
to  passing  these  requests  to  the  operating 
system,  which  would,  in  turn,  minimize 
security-related  interrupts.  This  dependency 
is  a  very  necessary  one  if  a  trusted  database 
management  system  is  to  coexist  with  a 
trusted  operating  system  successfully. 

Mfltwork  Services 

All  of  the  above  relationships  between 
the  database  management  system  and  the 
operating  system  have  been  general  case 
dependencies.  There  is  one  very  critical 
dependency  that  exists  in  the  distributed 
database  management  environment,  the  network 
server  function.  In  this  case,  the  data  and 
user  requests  are  transmitted  through  the 
distributed  system  to  any  and  all  appropriate 
hosts,  which  in  turn  return  the  requested 
information  to  the  sender.  The  network 
server  should  be  a  trusted  process 
communicating  with  other  trusted  network 
servers  who  presumably  reside  on  trusted 
operating  systems.  This  model  holds  for 
either  of  the  distributed  architectures 
discussod  above  because  either  trusted 
queries  eue  sent  without  the  benefit  of  a 
trusted  control  system  to  determine  where 
they  should  be  routed,  or  with  this  benefit. 
In  either  case,  the  netserver  function  is  a 
necessary  dependency  in  a  distributed 
database  environment  that  will  require 
further  exploration  before  such  an 
environment  can  be  considered  trusted. 

DATABASE  MANAGEMENT  SECURITY  FUNCTIONS 

Beyond  the  functional  dependencies 
between  the  operating  system  and  database 
management  systems,  there  are  security 

functions  which  must  be  performed  by  the 
database  management  system  independent  of  the 
operating  system.  Those  features  which  have 
an  effect  on  the  database  management  system's 
architecture  are  discussed  below. 

Label  Enforcement 

Perhaps  one  of  the  most  important 
security  relevant  functions  of  the  database 
management  system  is  that  of  label 
enforcement  at  fine  granularities.  Because 
current  trusted  operating  systems  may  ox-  may 
not  recognize  objects  for  labeling  that  are 
smaller  than  a  file,  the  database  managemi.  nt 
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functions  which  must  be  performed  by  the 
database  management  system  independent  of  the 
operating  system.  Those  features  which  have 
an  effect  on  the  database  management  system's 
architecture  are  discussed  below. 

Label  Enforcement 

Perhaps  one  of  the  most  important 
security  relevant  functions  of  the  database 
management  system  is  that  of  label 
enforcement  at  fine  granularities.  Because 
current  trusted  operating  systems  may  or  may 
not  recognize  objects  for  labeling  that  are 
smaller  than  a  file,  the  database  management 
system  must  take  responsibility  for  labeling 
at  lower  levels.  These  levels,  depending  on 
the  database  architecture,  are  the  relation, 
tuple  and  attribute.  Some  database 
management  systems  use  one  file  per  relation, 
therefore  they  are  only  concerned  with  label 
management  at  the  tuple  and  attribute  level 
and  leave  file  level  label  management  to  the 
operating  system.  Assuming  discretionary  and 
mandatory  access  control  information  has  to 
be  accounted  for,  the  database  management 
system  must  account  for  the  sensitivity  level 
of  the  data  as  well  as  the  access  control 
lists  attached  to  the  data,  for  example,  the 
sensitivity  level  may  be  top  secret  and  the 
discretionary  privileges  may  be  read  and 
update  for  a  particular  tuple.  How  low  the 
level  of  label  granularity  applies  depends  on 
the  security  policy  enforced  by  the  database 
management  system. 


Label  Integrity. 

How  is  label  integrity  maintained?  The 
sensitivity  level  used  in  labeling  can  be 
ascertained  from  the  user's  process 
authorization.  This  label  then  has  to  be 
attached  to  all  new  information  entered  into 
the  database  by  this  process.  Users  should 
not  be  able  to  modify  existing  labels,  nor 
should  they  have  the  ability  to  enter  or 
change  data  at  lower  or  higher  authorizations 
than  the  one  they  currently  are  using.  This 
interpretation  of  the  multilevel  environment 
is  highly  restrictive  and  most  users  would 
consider  it  to  be  a  user-hostile  denial  of 
service.  Label  modification  should  only 
occur  under  the  auspices  of  a  trusted 
process.  The  database  management  system  must 
automatically  append  the  appropriate  label  to 
the  data  upon  data  entry  into  the  database. 
Additionally,  the  database  management  system 
must  do  label  comparison  operations  to 
determine  if  update,  delete,  and  read 
operations  follow  the  security  constraints  of 
the  system.  These  functions  must  maintain 
label  integrity  to  ensure  correct  operation 
of  the  system  security  mechanisms  and 
maintain  the  system  security  policy.  This 
enforcement  is  also  an  important 
consideration  in  the  system  integrity  policy 
to  prevent  unintentional  or  malicious 
corruption  of  data. 

Query  Interpretation 

Another  area  of  security  responsibility 
is  that  of  query  interpretation.  The 
security  mechanism  of  the  database  management 
system  must  ensure  that  what  information  the 
user  requests  via  a  query  is  what  he 


receives,  consistent  with  the  security 
policy,  of  course.  This  means  the  integrity 
of  the  query  must  be  beyond  reproach.  In 
fact,  it  may  not  be  possible  to  provide  this 
level  of  query  integrity  without  trusting  the 
entire  database  management  system.  There 
must  be  no  chance  for  the  insertion  of  Trojan 
Horses  or  violation  of  the  system  integrity 
policy  before  the  query  is  processed. 
Additionally,  safeguards  must  be  in  place  to 
enforce  the  data  labels  and  mandatory  access 
control  policy  on  the  reply  to  the  query. 

Once  again,  the  issue  of  label  integrity  must 
be  addressed  if  correct  results  are  to  be 
obtained  from  the  database.  Labels  may  be 
appended  to  queries  to  ensure  their 
compliance  with  mandatory  access  controls,  in 
which  case  the  database  management  system  is 
responsible  for  secure  query  modification 
that  only  appends  the  subset  of  labels 
appropriate  to  a  given  process  and  query  and 
not  the  superset  of  all  known  labels  which 
may  reside  in  a  given  database.  In  the  event, 
query  modification  techniques  are  not 
employed,  the  database  management  system  must 
perform  a  filter  function  before  returning 
any  information  back  to  the  user  in  response 
appended  to  queries  mo  ensure  their 
compliance  with  mandatory  access  controls,  in 
which  case  the  database  management  system  is 
responsible  for  secure  query  modification 
that  only  appends  the  subset  of  labels 
appropriate  to  a  given  process  and  query  and 
not  the  superset  of  all  known  labels  which 
may  reside  in  a  given  database.  In  the  event 
query  modification  techniques  are  not 
employed,  the  database  management  system  must 
perform  a  filter  function  before  returning 
any  information  back  to  the  user  in  response 
to  a  query.  This  filter,  of  course,  must  be 
a  trusted  process  capable  of  examining  all 
returned  data  and  forwarding  only  that  which 
the  user  is  authorized  to  examine.  This  can 
be  especially  crucial  in  the  case  of  an 
update  request,  where  the  user  may  be  able  to 
examine  lower  level  data  but  can  modify  only 
those  components  of  a  tuple  which  are  at  his 
current  authorization  level.  Under  such 
circumstances,  labeling  of  attributes  and 
checking  of  authorization  privileges  are  very 
much  secure  databasa  management  functions. 

Indices 

The  use  of  indices  as  a  mechanism  to 
improve  response  time  also  causes  security 
concerns.  If  the  indices  are  derived 
directly  from  data,  or  if  their  use  can 
reveal  additional  information  about  the 
database  structure  or  contents,  then  their 
existence  raises  the  same  types  of  labeling 
and  query  modification  concerns  that  apply  to 
generic  data.  Indices  also  have  to  be  sorted 
by  mandatory  access  control  level  and  used  in 
a  manner  consistent  with  the  database 
management  system  security  policy. 

Therefore,  what  started  out  as  a  method  to 
improve  retrieval  performance  may  actually 
hinder  it  by  the  time  all  necessary  access 
mechanisms  are  enforced  on  the  indices.  In 
this  case,  use  of  the  indices  may  become  more 
burdensome  and  less  efficient. 

In  the  event  data  indices  exist  as  the 
result  of  a  random  hash  algorithm  or  other 
arbitrary  addressing  technique,  the  question 
of  where  the  indices  reside  must  be 
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addressed.  If  they  are  placed  at  the  highest 
authorization  level,  once  again  the  data 
filter  problem  exists.  If  the  indices  are 
located  at  the  user's  lowest  authorization 
level,  they  can  be  read  by  all  but  may 
unintentionally  divulge  information  about 
higher  level  data  and  could  be  exploited ' in  a 
statistical  inference  attack.  Location  of 
data  indices  and  their  use  therefore  becomes 
another  security  function  for  the  database 
■tanagement  system  to  balance  between  data 
security  and  system  usability. 

Data  Dictionary  Enforcement 

Indices,  however,  are  only  a  small 
segment  of  a  larger  security  concern  in 
database  management,  that  is,  how  to  enforce 
data  dictionary  constraints  securely.  The 
data  dictionary  contains  the  database  schema, 
data  conversion  algorithms,  and 
characteristics  of  data  attributes.  In  most 
systems,  the  data  dictionary  is  invoked  for 
data  validation  whenever  a  query  is  posed  or 
data  is  modified  or  added  to  the  database. 
Since  the  data  dictionary  could  contain  data 
validity  checks  which  might  divulge  sensitive 
information  about  data  value  ranges  for  a 
database,  it  should  have  associated  with  it  a 
level  of  trust  equal  to  the  highest  level  of 
trust  for  a  given  database.  The  data 
dictionary  also  may  contain  information  about 
discretionary  access  privileges  and  the 
location  of  database  files  which  contain  the 
actual  data.  Therefore,  the  data  dictionary 
also  becomes  an  active  entity  which  requires 
protection  beyond  that  which  is  normally 
available  in  untrusted  operating  systems. 

Perhaps  a  solution  is  to  divide  the  data 
dictionary  into  its  components  and  protect 
each  of  these  according  to  their  relative 
sensitivities,  such  a  solution  would  have  to 
be  determined  on  a  case  by  case  basis  for 
each  individual  database  and  data  dictionary 
combination,  thereby  eliminating  the 
possibility  of  a  generic  enforcement 
mechanism.  Another  solution  would  be  to 
translate  the  data  dictionary  into  an 
executable  form  which  could  be  kept  at  a 
level  accessible  to  all  users  while  the 
original  source  from  which  it  was  derived 
resides  at  the  highest  sensitivity  level 
under  the  further  protection  of  discretionary 
access  control  administered  by  the  database 
administrator  or  security  officer.  The 
executable  form  must  be  enforced  as  truly 
"execute  only"  permission.  That  is,  the  user 
must  not  be  able  to  reconstruct  the  source 
segment  nor  determine  sensitive  algorithms  or 
data.  This  method  allows  all  users  access  to 
the  Information  in  the  data  dictionary  while 
protecting  the  information  as  closely  as 
possible.  It  strikes  a  compromise  between 
total  access  and  complete  security  while 
preserving  the  required  functionality  for  the 
database  management  system.  Such  a 
compromise  must  be  qualitatively  measured  for 
each  trusted  application  according  to  the 
security  constraints  in  force  at  that  level 
of  trust. 

Database  Creation  and  Security  Functions 

Data  validation  and  retrieval  performance 
aids,  however,  make  one  important  assumption 
—  that  the  database  exists  and  has  been 
defined  and  created  by  a  user  of  the  system. 


This  becomes  a  security  concern  because  the 
data  files  and  supporting  structures  such  as 
the  data  dictionary  and  lock  table  should  be 
known  only  to  the  system  and  the  database 
administrator.  They  should  not  be  accessible 
to  the  common  user  accessing  data  through  the 
database  management  system.  To  make  them 
accessible  and  known  to  the  users  by  their 
appearance  in  the  directory  structure  invites 
tampering.  For  example,  if  th*  system  does 
mandatory  and  discretionary  access  control  to 
the  file  level,  and  the  database  management 
system  supports  one  file  per  relation  and 
uses  the  system's  access  control  mechanisms, 
there  is  nothing  to  force  the  user  through 
the  database  management  system  to  access  the 
entire  relation,  whether  he  has  access  rights 
established  on  a  per  tuple  basis  or  not.  A 
simple  copy  or  print  command  would  result  in 
the  compromise  of  all  data  stored  in  such  a 
relation,  not  to  mention  all  per  tuple 
privilege  information  for  the  relation.  At 
this  point,  it  is  a  small  job  to  decipher  the 
relation  formation  and  complete  the  data 
compromise. 

The  problem  becomes  even  more  complex  in 
the  case  of  a  multilevel  operating  system. 
Here  the  database  manager  somehow  has  to 
segregate  data  according  to  the  user's 
authorized  level,  but  merge  it  to  provide 
responses  to  his  requests  consistent  with  the 
system's  security  policy.  That  is,  the  data 
has  to  be  stored  in  such  a  way  as  to  maintain 
the  mandatory  access  control  policy  of  the 
system  while  providing  the  user  with  his 
information.  The  database  management  system 
has  to  maintain  the  appropriate  data  files  at 
the  correct  levels,  or  store  the  data  at  the 
user's  highest  authorization  and  distribute 
it  from  there. 

The  majority  of  work  on  multilevel  data 
management  to  date  has  assumed  the  database 
existed  and  worked  from  there.  Very  little 
has  been  done  on  the  potential  covert 
channels  that  might  be  created  during  the 
initialization  of  a  multilevel  database,  or 
techniques  to  minimize  them. 

view  Enforcement 

Related  to  the  problems  of  database 
creation  is  the  area  of  view  or  subschema 
enforcement.  This  function  enforces  certain 
configurations  of  the  basic  database  as 
created  by  the  database  administrator  on  the 
database's  users.  Historically,  views  have 
been  defined  in  the  data  dictionary/ database 
creation  files.  Their  enforcement  upon  the 
database  becomes  critical  in  multilevel  data 
management.  For  example,  the  database  as  a 
whole  could  sxist  at  a  variety  of  levels  with 
views  used  to  ensure  that  the  user  only  sees 
data  consistent  with  his  authorization  level. 
Views  can  also  be  used  to  enforce 
discretionary  access  to  the  database  if  one 
view  is  used  for  each  discretionary  access 
right  and  composite  views  can  exist  to  allow 
users  multiple  privileges.  For  example, 
separate  views  exist  for  reading  and  writing 
data  to  a  particular  relation  and  the  two 
views  are  merged  to  create  a  read/write  view 
for  a  particular  user.  Once  again,  if  the 
database's  data  files  are  accessible  with  the 
standard  system  file  commands,  views  are  easy 
to  circumvent.  Additionally,  combinations  of 
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views  may  divulge  more  information  than 
single  views  authorize  the  user  to  see.  View 
mechanisms  may  also  be  used  to  protect  a 
database  against  inference  attacks  and  to 
ensure  data  integrity.  In  light  of  these 
potential  security  uses  of  views,  their 
secure  enforcement  becomes  a  prominent 
security  service  that  must  be  trusted  to  work 
correctly. 

Trusted  Process  Mechanism 

As  was  noted  above  in  the  discussion  of 
operating  system  dependencies,  creation  and 
use  of  a  trusted  process  mechanism  in  the 
database  management  system  can  become  a  major 
security  concern.  In  this  context  the 
trusted  process  becomes  responsible  for  the 
enforcement  of  the  database  security  policy 
and  ensures  its  consistency  with  the 
operating  system's  security  policy.  It  is 
this  process  which  takes  the  user's  request 
and  applies  appropriate  logic  to  it  to  result 
in  an  updated  view  of  the  database.  If  a 
user  were  to  request  an  update  of  a  tuple  in 
the  database,  the  trusted  process  would  be 
responsible  for  validating  his  access 
privileges  on  the  relation  and  on  each 
attribute  of  the  relation,  if  necessary.  It 
would  also  be  responsible  for  ensuring  the 
integrity  of  the  database,  that  is,  checking 
the  lock  table  prior  to  applying  a 
transaction  to  the  database  to  ensure  each 
user  gats  consistent  information.  The 
trusted  processes  become  even  more  critical 
in  the  multilevel  environment.  Here  they 
must  still  ensure  that  data  integrity 
constraints  and  locking  protocols  are 
followed  as  well  as  handle  the  multilevel 
security  policy  axioms.  In  the  case  of  the 
database  machine,  these  processes  are  the 
primary  components  of  the  security  kernel.  A 
database  management  system  working  in 
conjunction  with  a  trusted  operating  system 
would  interface  its  trusted  processes  to  the 
operating  systems 's  security  kernel,  creating 
a  large  opportunity  for  covert  channels  and 
subsequent  system  exploitation.  In  the  event 
the  system  permits  execution  af  user  data 
segments,  this  exploitation  threat  is 
substantial . 

Auditing  .small . Qbjegte 

Another  requirement  to  maintain  data 
integrity  is  the  need  for  auditing  at  a  finer 
level  of  object  granularity  than  the  file 
level  objects  most  general  purpose  trusted 
systems  audit.  The  majority  of  operating 
system  audit  tools  would  note  that  a  user 
accessed  or  attempted  to  access  a  file  and 
may  or  may  not  have  modified  it.  Special 
audit  tools  used  for  system  debugging  account 
for  arguments  passed  into  and  out  of 
subroutines  that  are  referenced.  In  the  case 
of  secure  database  management,  a  combination 
of  these  two  functions  is  required.  An  audit 
that  notes  only  that  the  user  accessed  a 
database  is  not  sufficient  to  address  data 
security  concerns.  For  a  database  management 
system,  a  useful  audit  function  would 
probably  include  the  data  accessed  and  the 
before  and  after  image  of  any  data  modified 
by  a  user  request.  The  audit  log  also  has  to 
be  able  to  account  for  the  possibility  of 
multilevel  data  manipulation  by  either 
existing  at  each  level  or  at  the  user's 


highest  authorization.  In  this  case  the 
audit  log  will  grow  rapidly  into  something 
very  large  with  minimal  utility.  Therefore, 
for  a  trusted  audit  to  exist  successfully  in 
a  database  management  environment  audit 
reduction  tools  must  exist,  including  pattern 
recognition  tools  that  could  detect  attempted 
inference  attacks.  Both  types  of  tools 
should  exist,  otherwise  valuable  pattern 
information  could  be  lost  during  audit 
reduction  and  an  attack  could  ocaur  and  never 
be  detected  through  the  audit  logs. 

Such  an  audit  log  could  also  be  used  to 
handle  trusted  database  recovery  as  well. 
Recovery  for  a  database  management  system 
becomes  a  bit  more  complicated  than  recovery 
for  a  generic  operating  system.  The 
operating  system  has  to  save  its  hardware 
context  (the  values  of  its  registers  at  the 
time  of  crash)  and  write  all  modified  pages 
back  out  to  disk.  It  makes  no  claims  with 
regard  to  data  validity  within  those  pages, 
and,  if  it  cannot  get  the  page  back  on  disk, 
may  replace  it  with  a  page  of  null  values. 
This  type  of  nonrecoverable  error  would  be 
easily  detected  in  the  case  of  an  individual 
text  file,  for  example,  but  a  database  can  be 
much  larger  than  a  single  page  and  therefore 
such  an  error  could  conceivably  escape 
detection  until  data  from  that  particular 
page  was  needed  and  not  found.  The  database 
recovery  facility  must  be  able  to  determine 
if  its  files  were  affected  by  a  crash,  if 
pages  within  a  file  were  af footed,  and,  if 
so,  to  restore  the  appropriate  information. 
The  information  from  the  audit  logs  can  be 
used  to  determine  if  transactions  have  been 
committed  and  to  repair  damaged  databases. 

In  trusted  mandatory  access  control  systems, 
the  integrity  of  data  labels  must  also  be 
validated.  Additionally,  if  the  system  is 
multilevel  secure  then  the  data  must  be 
distributed  to  each  level  securely.  The 
recovery  mechanism  may  have  to  deny  service 
to  database  users  while  it  is  validating  the 
database  after  the  system  has  finished  its 
own  recovery  to  ensure  as  accurate  a 
reconstruction  of  the  database  as  is 
possible.  This  technique  requires  that  the 
database  recovery  manager  must  be  added  to 
the  trusted  processes  resident  in  the 
database  management  system. 


No  discussion  of  database  security 
mechanisms  would  be  complete  without  the 
mention  of  data  inference  and  integrity 
control  mechanisms.  Data  inference  —  the 
unintentional  compromise  by  deduction  of 
unauthorized  information  due  to  combinations 
of  the  possession,  known  existence,  known 
absence,  chronology,  and  location  of 
authorized  information  —  is  most  frequently 
exploitable  in  data  at  either  end  of  a 
standard  distribution.  That  is,  the  most 
extreme  values  are  the  most  vulnerable. 

There  are  several  techniques  to  protect 
against  inference  attacks,  but  the  majority 
of  them  render  the  database  useless  for 
precisely  formulated  queries  with  specific 
responses  because  they  involve  the  corruption 
of  t!ie  original  data  in  soma  way.  An 
alternative  approach  to  inference  control  is 
the  construction  of  a  rule-based  semantic 
layer  between  the  logical  database  design  and 
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the  physical  implementation  of  that  schema. 
This  rule-based  system  would  use  statistical 
information  about  the  database  composition  to 
determine  the  probability  of  compromise  if 
the  requested  information  were  divulged.  If 
the  probability  of  compromise  were  high,  the 
data  would  not  be  revealed.  It  is  possible, 
however,  that  the  performance  penalties  paid 
for  inference  control  may  make  a  database 
management  system  unusable  in  an  interactive 
system. 

The  concerns  of  data  integrity  are  more 
acute  and  offer  more  promising  near-term 
solutions  than  those  of  data  inference.  Data 
integrity  in  the  database  management  sense  is 
defined  as  the  correctness  of  the  data  itself 
and  any  associated  data  structures  and 
information  required  to  access  the  database. 
The  principal  concerns  in  the  area  of 
database  integrity  are  associated  with 
locking  mechanisms  for  the  update  and 
addition  of  information  to  a  database.  If  a 
user  is  updating  the  database,  an  exclusive 
lock  mechanism  must  deny  other  users 
attempting  to  update  the  database  or  retrieve 
information  access  for  the  duration  of  the 
update.  It  may  be  possible  to  preserve 
uncommitted  transactions  and  apply  them  to  a 
database  when  the  locking  process  releases 
its  locks,  thereby  freeing  the  database  for 
other  users.  However,  there  may  be 
complications  with  this  strategy  in  that 
there  is  no  guarantee  that  conflicting 
transactions  would  not  be  applied  to  the  same 
data.  For  example,  two  users  wish  to  modify 
status  information  and  attempt  to  commit 
transactions  at  the  same  time.  One  may  aay 
the  status  is  complete,  the  other  the  status 
is  pending.  Such  types  of  conflict  cannot  be 
resolved  automatically  by  the  system  and 
would  require  human  intervention  of  some 
sort.  The  update  problem  becomes  more 
complicated  in  the  multilevel  sense  in  that 
users  at  different  authorizations  could  well 
be  modifying  attributes  of  the  same  tuple  at 
the  same  time.  The  database  management 
system  must  apply  the  transactions  as 
specified  by  the  security  policy  of  the 
operating  system.  These  integrity 
constraints  do  not  include  the  case  of 
unauthorized  intentional  modification  of  data 
by  an  authorized  users.  In  this  case,  a 
user  modifies  a  file  at  a  higher 
classification  by  writing  up  into  it, 
although  he  cannot  read  the  file  afterwards 
from  his  current  authorization  level.  There 
is  no  known  security  policy  that  addresses 
this  concern  and  maintains  a  multilevel  user 
environment. 

There  are  integrity  concerns  with  the 
locking  mechanism.  The  lock  table  may  not 
reflect  the  current  status  of  the  database. 
For  example,  if  the  system  crashed  after  the 
user  process  committed  a  transaction  but 
before  he  could  release  his  look  on  the 
database,  denial  of  service  to  other  users 
could  be  based  on  incorrect  information 
because  the  lock  table  is  left  in  an 
inconsistent  state.  Given  the  option,  the 
database  recovery  manager  could  possibly 
resolve  a  inconsistent  lock  table  from  the 
audit  logs.  It  could  not  resolve  an 
inconsistent  database  from  a  consistent  lock 
table  in  most  cases. 


Denial  of  Service 

Beyond  these  integrity  issues,  there  are 
the  questions  of  denial  of  service  in  a 
multilevel  environment.  A  user  at  a  higher 
authorization  level  could  have  the  database 
exclusively  locked.  This  fact  must  be  hidden 
from  the  lower  level  user  t  prevent  a  covert 
signalling  channel.  However,  the  lower  level 
user  could  not  access  the  database  if  the 
higher  level  user  was  working  with  a 
particular  page.  It  has  been  proposed  that 
creating  mirror  image  tuples  at  the 
appropriate  levels  would  solve  this  problem; 
however,  the  question  then  becomes  which  user 
has  the  most  current  version  of  the  tuple  and 
which  user  is  working  with  data  that  has  been 
modified  without  his  knowledge. 

The  above  concerns  are  only  meant  to 
highlight  the  severity  and  importance  of  the 
database  management  system's  security 
functions.  They  are  not  meant  to  be  complete 
discussions  of  the  subjects,  but  rather  to 
show  the  magnitude  and  impact  of  the  security 
constraints  which  will  exist  in  a  trusted 
database  management  system. 

EXPLORATORY  DATABASE  ARCHITECTURES 

Given  the  number  of  dependencies  between 
the  operating  system  and  the  database 
management  system,  the  security  t unctions  the 
database  management  system  must  perform,  and 
the  state  of  current  technology,  can  anything 
be  done  to  minimize  the  security  problems  in 
database  management?  The  majority  of 
currently  available  database  management 
systems  address  the  discretionary  access 
control  constraints  in  some  fashion,  even  if 
they  are  easy  to  compromise  by  experienced 
programmers .  These  discretionary  access 
controls  do  perform  the  function  of 
protecting  the  user  and  the  database  from 
unintentional  mistakes  that  could  cause  data 
leakage.  They  do  not  protect  against 
deliberate  attacks.  The  few  database 
management  systems  that  are  hosted  on 
multilevel  systems  do  work  well  with  the 
mandatory  access  controls,  but  they  do  not 
support  multilevel  objects  and  cannot 
function  at  more  than  a  single  level  per 
database. 

What  is  needed  then,  is  a  method  to 
enforce  discretionary  access  controls 
securely,  force  all  access  to  the  database 
through  the  database  management  system  to 
eliminate  the  possibility  of  copying  data 
files  through  the  file  system  commands, 
enforce  mandatory  access  control,  and  work  in 
a  multilevel  environment  without  creating 
large  covert  channels.  To  do  so  efficiently 
with  minimal  impact  on  user  response  time  is 
a  necessary  condition  if  the  product  will  be 
usable.  The  question  then  becomes  how  to 
meet  all  of  these  requirements  in  a  database 
management  system  that  can  be  implemented  in 
the  near  future.  The  1982  Summer  Study  on 
Multilevel  Data  Management  proposed  three 
different  architectures  to  answer  these 
requirements  (8).  This  section  summarizes 
these  three  architectures  and  includes  a 
fourth  architecture  that  the  authors  believe 
may  offer  a  solution. 
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Ksrnsl-Ksrnsl 

The  first  of  these  architectures,  the 
kernel-kernel  approach,  uses  the  operating 
system  security  kernel  as  a  foundation  for  a 
database  security  kernel  that  acts  as  a 
trusted  mediator  between  the  user's  requests 
and  the  operating  system  security  kernel. 

The  database  kernel  is  responsible  for 
labeling  at  a  granularity  finer  than  the 
operating  system's  smallest  labeled  object. 

The  operating  system  does  labeling  at  its 
granularity  levels  and  is  responsible  for  the 
enforcement  of  the  system  security  policy  on 
the  database  management  system.  The 
operating  system  ensures  that  the  user  can 
only  modify  data  at  his  current  authorization 
level  through  mandatory  access  controls.  The 
database  management  system  attaches  the 
appropriate  labels  to  the  data  and  enforces 
its  discretionary  access  controls  on  its 
databases.  Recovery  operations  are  a  joint 
effort  between  the  databasa  recovery  manager 
and  the  operating  system's  recovery 
utilities.  The  operating  system  recovers  to 
the  file  level  and  informs  the  database 
recovery  manager  that  there  was  damage  done 
to  items  under  its  control.  The  database 
recovery  manager  then  examines  its  databases 
and  does  what  it  can  to  make,  things 
consistent.  Comprehensive  system  audit  tools 
ore  customized  to  handle  the  database  audit 
requirements  by  adding  audit  reduction  and 
pattern  recognition  features.  Authentication 
of  the  user  is  done  by  the  operating  system 
and  the  database  management  system  may  take 
advantage  of  that  information  or  use  the 
system  authentication  subroutines  to  perform 
its  own  authentication. 

The  kernel-kernel  approach  should  allow 
retrofit  of  the  database  security  kernel  on  a 
kernellzed  trusted  operating  system.  The 
primary  area  of  concern  in  this  approach  is 
the  definition  of  the  boundaries  of  the 
database  security  kernel.  In  the  worst  case, 
the  databases  themselves  must  be  within  the 
bounds  of  the  kernel,  making  it  so  large  and 
complex  that  correct  operation  could  not  be 
substantiated,  in  the  bast  case,  the  kernel 
may  not  be  substantially  larger  than  the 
operating  system  security  kernel  and  would 
have  little  effect  on  performance  or 
validity. 

This  design  may  take  advantage  of  the 
security  features  of  the  underlying  operating 
system  for  mandatory  and/or  discretionary 
access  control.  This  technique  could 
conceivably  be  applied  to  any  database 
management  system  that  resides  on  a 
kernelized  operating  system  host. 

Performance  constraints  on  the  database 
management  system  would  exist  if  the 
performance  of  the  operating  system  security 
kernel  was  poor  si  nee  it  must  interact  with 
the  database  kernel  for  most  operations. 
Covert  channels  may  exist  because  of  the 
interaction  between  the  two  kernels.  Such 
covert  channels  also  increase  the  probability 
of  Trojan  Horse  attacks  against  the  databasa 
management  system  by  cooperating  processes  at 
various  sensitivity  levels.  Additionally, 
the  no-v/iita-dovr.  constraint  of  the  Bell- 
LaPadula  security  model  prevents  data  from 
being  stored  at  a  sensitivity  below  the 
current  authorized  sensitivity  level  of  the 


user,  making  this  system  very  user-hostile 
for  data  update  operations.  To  minimize  the 
user  interface  problems,  larger  covert 
channels  would  have  to  be  permitted  and  a 
generic  downgrade  function  would  have  to 
exist  in  the  database  management  system 
trusted  software  and  be  accessible  to 
authorized  database  users.  This  approach  is 
very  attractive  in  that  the  amount  of  trusted 
code  to  be  added  to  the  system  is  relatively 
small  because  the  database  management  system 
uses  the  operating  system  for  the  majority  of 
its  trusted  functions,  making  it  easy  to 
retrofit  into  an  existing  system.  However, 
the  user  interface  to  this  database 
management  system,  and  the  potentially  large 
covert  channels  may  not  make  it  useful  as 
more  than  a  demonstration  project.  Only  if 
past  experience  with  kernelized  architecture 
performance  constraints  can  be  incorporated 
into  the  system  design  would  such  an 
architecture  be  feasible  for  secure  database 
management  systems. 


The  second  exploratory  architecture, 
cryptographic  sealing,  uses  encrypted 
checksums  to  determine  the  authorization 
label  and  access  rights  to  the  data.  When  a 
tuple  is  created,  the  encrypted  access 
information  is  appended  to  it.  Every  time 
the  data  is  accessed,  the  sensitivity  labels 
are  decrypted  with  keys  corresponding  to  each 
access  class.  If  the  data  is  decrypted 
proper,  it  is  forwarded  to  the  user.  If  the 
correct  key  is  not  located,  the  data  is  not 
returned.  A  variation  on  this  method  uses 
query  modification  to  append  the  correct 
sensitivity  label  to  the  query  and  stores  the 
labels  as  another  attribute  with  the  rest  of 
the  data.  The  label  fields  are  then  compared 
as  part  of  the  normal  quory/ response 
processing  with  matching  labels  required 
before  an  item  is  reported  to  the  user.  In 
these  examples,  there  is  additional  overhead 
for  encryption/decryption  and  query 
modification.  The  database  management  system 
is  responsible  for  all  label  integrity  and 
access  control  enforcement.  Recovery  beyond 
the  file  level  is  handled  in  much  the  same 
way  as  the  kernel-kernel  approach  with  the 
database  recovery  manager  responsible  for 
label  integrity  and  data  correction  if 
necessary. 

The  principal  disadvantage  to  this  method 
is  the  time  involved  to  encrypt  »nd  decrypt 
the  labels  and  the  additional  storago 
required  for  them,  since  sensitivity  labels 
are  not  usually  stored  with  data. 

Sensitivity  keys  must  also  be  stored  with 
care  so  they  may  not  compromise  the  system's 
security  mechanisms.  There  is  also  a 
possibility  of  compromise  through 
unintentional  or  intentional  mismanagement  of 
the  encryption  keys  and  checksums.  The 
advantage  to  this  method  is  that  the  database 
management  system  becomes  responsible  for  all 
access  control  functions  and  performs  as  a 
simple  access  filter.  This  is  especially 
true  in  the  variation  on  this  technique  that 
encrypts  the  entire  tuple  and  decrypts  it 
only  when  necessary.  The  fact  that  the  only 
trusted  component  in  the  system  is  the  filter 
makes  it  simpler  to  verify  correct  operation 
of  the  software  and  a  relatively 
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straightforward  approach.  Potentially,  this 
system  offers  a  high  degree  of  trust  and  can 
be  incorporated  into  an  existing  database 
management  system  with  minimal  effort,  if  the 
constraints  involved  in  key  management  can  be 
resolved. 

Physical  Data  Segregation  ( Backend  Database 
Machined 

A  third  approach,  that  of  physical  data 
segregation,  is  best  suited  to  the  dedicated 
database  machine  environment.  In  this  method 
the  mandatory  access  control  is  accomplished 
by  independent  processors  and  disks  which  are 
labeled  by  sensitivity  level.  Each 
independent  processor  works  on  a  query  passed 
to  it  by  a  central  controller  and  returns  the 
requested  information  under  its  control  that 
meets  the  conditions  of  the  query.  The 
control  processor  determines  which 
independent  processors  to  forward  the  query 
to  and  merges  the  independent  responses  into 
one  consolidated  response.  The  independent 
processors  arc  responsible  for  discretionary 
access  control  on  their  own  data  and  the 
control  processor  is  responsible  for 
mandatory  access  control  enforcement. 

One  of  the  disadvantages  of  this  approach 
is  the  extra  complement  of  processors  and 
disks  associated  with  each  level. 
Additionally,  each  device  pair  must  be 
responsible  for  its  own  recovery  and  auditing 
functions.  This  method  also  has  to  cope  with 
components  of  the  distributed  database 
locking  problem  in  that  it  may  be  able  to 
obtain  locks  for  high  level  data  but  not  for 
low  level  data,  resulting  in  denial  of 
service  to  a  process  which  requires  both 
levels  to  develop  an  answer. 

The  major  advantage  is  that  the  security 
controls  are  relatively  centralized  in  the 
control  processor,  thereby  defining  the 
bounds  of  the  database  security  kernel  and 
its  interfaces  to  nontrusted  processes.  This 
technique  offers  a  straightforward  approach 
to  secure  database  management.  However,  if 
too  many  features  are  incorporated  into  the 
front-end  controller,  the  security 
constraints  may  become  very  complicated. 


The  fourth  primary  architectural 
alternative  is  a  operating  system  security 
kernel  designed  with  database  security 
features  in  mind.  This  type  of  architecture 
cannot  be  incorporated  into  a  system,  it  has 
to  be  designed  in  and  exist  from  the  start. 
The  time  usually  spent  determining  where  to 
place  security  constraints  is  instead  spent 
on  design  of  the  system  from  scratch.  The 
implementation  allows  the  database  security 
policy  to  be  reflected  in  the  system  security 
policy.  The  operating  system  can  take 
responsibility  for  all  labeling  functions  and 
the  enforcement  of  the  mandatory  and 
discretionary  access  control  policies.  The 
database  management  system  is  responsible  for 
additional  security  requirements  such  as 
inference  control.  Audit  functions  can  be 
handled  by  the  system  audit  controls  since 
the  system  recognizes  labels  on  objects 
smaller  than  a  file  in  this  scenario. 

Recovery  procedures  could  be  managed  by  the 


operating  system  since  it  understands  the 
smaller  granularity  and  the  labels  associated 
with  it. 

This  technique  may  also  prove  very  costly 
in  that  it  requires  the  expansion  of  the 
security  kernel  to  incorporate  the  database 
security  kernel's  functions.  There  may  also 
be  performance  problems  that  would  render  the 
system  user-hostile  in  interactive 
environments.  Past  experiences  with  large 
operating  system  kernels  have  demonstrated 
that  system  performance  and  the  size  of  the 
kernel  are  related,  with  large  kernels  being 
harder  to  validate  and  slower  (9).  In  this 
context,  much  of  the  validation  information 
and  audit  functions  would  probably  have  to  be 
implemented  in  hardware  to  ensure  adequate 
response  time  for  the  user's  applications. 
This  approach  would  only  be  feasible  if  the 
operating  system  kernel  could  be  extended 
without  compromising  its'  level  of  trust  or 
its'  ability  to  be  analyzed  for  security 
flaws.  Therefore  a  dedicated  database 
machine  architecture  is  implied  oecause  the 
system  would  be  tailored  to  address  database 
security  considerations. 

CONCLUSIONS 

There  are  several  functional  dependencies 
between  the  database  management  system’s 
security  functions  and  the  operating  system's 
security  functions.  These  dependencies  would 
make  it  very  difficult  if  not  impossible  to 
develop  a  trusted  database  management  system 
on  an  untrusted  operating  system.  They 
would  also  make  it  hard  to  trust  a  database 
management  system  beyond  the  level  of  trust 
available  in  the  operating  system.  For 
example,  it  would  be  difficult  for  a  database 
management  system  to  enforce  strong  mandatory 
access  controls  without  the  underlying 
support  of  an  operating  system  trusted  at  the 
B2  level  of  the  Trusted  Computer  Systems 
Evaluation  Criteria  or  higher. 

It  is  also  very  difficult  to  determine 
how  much  of  the  database  management  system 
needs  to  be  trusted.  Any  portion  of  the 
system  that  has  the  potential  to  modify  the 
actual  data  or  audit  logs  could  be  considered 
part  of  this  security  kernel,  in  theory, 
database  management  systems  support  separable 
functions,  however,  in  practice,  there  is 
some  debate  as  to  the  number  of  commercial 
database  management  systems  constructed 
totally  out  of  modular  sections.  Many  of 
today's  database  management  systems  are 
highly  integrated  and  the  modules  which 
support  these  individual  functions  are  not 
always  distinct  or  interchangeable. 

Therefore,  since  it  is  difficult  to 
distinguish  between  the  functional  modules, 
different  database  management  system  designs 
require  different  portions  of  the  database 
management  system  tc  be  trusted.  This  leads 
to  the  conclusion  that  those  portions  of  a 
database  management  system  that  must  be 
trusted  are  determined  by  three  primary 
factors:  1)  the  design  of  the  database 
management  system,  2)  the  design  of  the 
security  mechanism  within  the  database 
management  system,  and  3)  the  interrelation 
between  the  operating  system  security 
mechanisms  and  the  database  management 
system's  security  mechanisms  and  policy. 


Beyond  these  conclusions,  there  have 
been  arguments  that  the  only  way  to  ensure 
that  the  data  is  protected,  especially  in  the 
multilevel  environment,  is  to  include  the 
database  as  a  protected  object  that  is 
isolated  from  the  control  of  the  standard 
system  file  structure  to  soma  degree.  This 
eliminates  the  possibility  of  access  through 
standard  system  file  commands  and  forces  the 
user  to  access  the  database  through  the 
database  management  system.  There  still  must 
be  some  consideration  of  applications 
provided  with  the  database  management  system 
(spreadsheets,  report  generators,  etc.)  that 
manipulate  data  after  it  has  been  retrieved 
but  before  it  is  delivered  to  the  user  in  the 
requested  format,  and  easy  query  language 
interfaces  that  convert  user  generated 
English  statements  into  structured  Query 
Language  expressions  that  can  be  executed  by 
the  query  processor. 

The  incorporation  of  security  features 

into  a  commercial  database  management  system 
is  not  an  easy  thing  to  do.  Beyond  finding  a 
way  to  aaouro  or  control  the  operating  system 
interfaces,  a  large  portion  of  the  database 
management  system  itself  might  require 
revision  or  replacement  to  eliminate  or 
narrow  potential  covert  channels.  The 
dependencies  between  the  operating  system  and 
the  database  management  system  are  very 
complex.  In  the  distributed  database 
environment,  they  become  even  more  difficult 
because  network  security  must  also  be 
considered,  with  the  backend  database 
machine,  the  question  of  how  much  confidence 
exists  in  the  host  request  mechanism  must  be 
addressed. 

From  the  four  alternative  exploratory 
architectures  discussed,  perhaps  the 
architecture  with  the  highest  potential  for 
the  greatest  security  is  the  fourth 
alternative,  the  customized  combined 
operating  system/database  management  system 
kernel  approach.  This  approach  would  address 
the  efficiency  concerns  inherent  with 
security  kernels  as  well  as  the  performance 
considerations  for  database  management 
systems.  The  security  policies  of  the 
database  management  system  and  the  operating 
system  could  be  more  easily  reconciled 
Because  they  would  be  developed  concurrently 
and  with  a  greater  degree  of  confidence  that 
the  end  product  was  secure. 

A  trusted  database  management  system  wi1 1 
not  be  built  overnight.  Father,  it  must  be"" 
carefully  constructed  to  afford  the  maximum 
protection  possible  to  the  data,  a  sufficient 
audit  trail,  and  a  thorough  recovery'  process 
to  eliminate  data  inconsistencies  that  may 
result  from  crash.  All  of  these  features 
must  exist,  and  performance  penalties  must  be 
minimized.  it  may  not  be  possible  to 
incorporate  all  of  these  features  in  a  near- 
term  solution.  However,  worked  examples  of 
the  various  security  techniques  must  be 
created  now  to  be  incorporated  into  the 
secure  data  management  systems  of  tomorrow. 

To  do  otherwise  would  result  in  the  ultimate 
secure  system  —  one  so  secure  that  nobody 
could  afford  the  price  of  its  use. 
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INTRODUCTION 

This  paper  desoribes  four  guidelines  and 
standards  that  have  been  or  are  being 
developed  in  the  Standards  Division  of  the 
National  Computer  Security  Center.  These 
documents  are:  DoD  5200.28-STD,  DoD  Trusted 
computer  Systems  Evaluation.  Criteria .  Draft 
DoD  Directive  5200.28,  Security  Requirements 
for  Automated  Information  _£v.atemB..JAIS)  , 
Trusted  Network  Guideline,  and  A  Guideline  on 
Office  Automation  Security. 

POP  5200.28-STD 

The  Department  of  Defense  Trusted  Computer 
System  Evaluation  criteria,  csc-std-ooi-83, 
was  signed  as  a  DoD  standard  by  Mr.  Latham, 
the  Assistant  Secretary  of  Defense  for 
Command,  Control,  Communications  and  Intel¬ 
ligence  (ASD(C3I) ) ,  in  December,  1985.  The 
standard  is  DoD  5200.28-STD,  entitled 
Department  of  Defense  Trusted  computer  ...System 
Evaluation  Criteria, 

The  standard  is  nearly  a  duplicate  of  CSC- 
STD-001-83.  During  coordination  within  tho 
DoD,  however,  some  changes  ware  agreed  upon 
between  ASD(C3I) ,  the  NCSC,  and  the  DoD 
components.  A  document  was  created  that 
contains  a  summary  of  tho  changes  that  were 
made.  This  document  is  being  distributed 
along  with  the  standard.  The  standard  has 
been  printed  (It,  too,  has  an  orange  cover.) 
and  copies  are  available  from  the  NCSC. 


DRAFT  DPP  DIRECTIVE  S&fl&iM 


Background .  The  Secretary  of  Defense  tasked 
the  Assistant  Secretary  of  Defense  for 
Command,  Control,  Communications  and  Intel- 
ligence,  ASD(C3I),  in  collaboration  with  the 
NCSC  to  revise  the  directive.  To  accomplish 


the  task,  a  task  force  chaired  by  NCSC  was 
formed  of  DoD  representatives  who  have 
computer  security  expertise,  are  familiar 
with  current  DoD  policy,  and  are  aware  of 
their  own  components'  security  needs.  A 
draft  directive  was  produced  by  the  task 
force  and  sent  to  ASD(C3I)  for  their  review 
and  coordination  among  the  DoD  components. 


Overview  of  the  Draft  Directive.  The  SECDEF 
had  three  objectives  to  be  accomplished  in 
the  revised  directive.  The  first  objective 
was  to  ensure  that  the  directive  applies  to 
all  computer-driven  information  systems.  The 
second  objective  was  to  add  policy  guidance 
for  including  computer  security  requirements 
in  AIS  procurements.  The  third  objective  was 


to  incorporate  the  use  of  computer  security 
standards  and  guidelines.  Thssa  objectives 
were  accomplished  by  the  task  force  during 
the  rewrite. 

The  third  objective  was  accomplished  by 
introducing  the  DoD  5200.28-STD  in  the  draft 
and  by  requiring  its  use  in  the  selection  of 
security  features  that  will  meet  the  re¬ 
quirements  statsd  in  the  directive.  Without 
going  into  detail,  tho  following  is  a  brief 
description  of  how  the  draft  directive 
incorporates  ths  DoD  standard: 

All  AISs  that  handle  classified  or  sensitive 
information  must  have  security  safeguards 
that  are  adequate  to  meet  a  set  of  minimum 
requirements  specified  in  the  draft  di¬ 
rective.  These  minimum  requirements  are 
similar  to  those  listed  in  the  original  DoD 
directive,  but  they  havn  been  reworded  and 
updated.  The  minimum  requirements  include 
such  things  as  individual  accountability, 
audit  trail,  aoaess  control,  physical 
controls,  and  appropriate  marking  of  output 
products . 

For  those  AISs  that  will  operate  in  the 
dedicated  security  mode,  the  set  of  minimum 
requirements  may  be  met  by  automated  or 
manual  means,  and  there  are  no  further 
requirements  to  be  met. 

For  those  AISs  that  will  operate  in  the 
system  high  or  multilevel  or  partitioned 
security  modes,  where  there  is  increasing 
risk  involved  in  the  protection  of  the 
information  being  handled  by  the  AISs,  there 
is  further  guidance  in  the  draft  directive 
that  must  be  followed  in  order  to  determine 
the  additional  security  safeguards  that  are 
necessary. 


Tha  guidance  in  the  draft  is  comprised  of  a 
series  of  steps  that  must  be  taken  to 
determine  the  requirements  that  must  be  met 
for  a  particular  AIS.  The  first  stsp  is  to 
determine  the  security  mode  of  operation  from 
among  the  modes  that  I  listed  above.  The 
second  step  is  to  determine  tha  minimum  user 
clearance,  or,  more  precisely  stated,  the 
maximum  clearance  of  the  least  cleared  user. 
The  third  step  is  to  datermine  the  maximum 
sensitivity  of  the  information  handled  by  the 
AIS.  The  information  derived  in  steps  two 
and  three  are  assigned  values,  and  in  step 
four  the  valuos  are  used  to  produce  a  risk 
index.  In  step  five  the  risk  index  is  mapped 
to  a  particular  evaluation  class  in  the  DoD 
standard.  As  an  example,  a  risk  index  of  2 
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maps  directly  to  class  B2  in  the  DoD 
standard,  indicating  that  the  AIS  must  meet 
B2  requirements.  The  information  in  these 
five  steps  is  the  same  information  as  that 
found  in  the  publication  entitled  Computer 
Security  Requirements  --  Guidance -for 
Applying  the  DoD  Trusted  Computer._SYateiB 
Evaluation  Criteria  in  Specific  Environments , 
that  was  produced  by  the  Standards  Division 
in  June  of  1985. 

Several  other  changes  to,  or  departures  from, 
the  original  directive  were  made  by  the  task 
force.  For  instance,  the  current  directive 
applies  to  the  protection  of  classified 
information,  whereas  the  draft  applies  to  the 
protection  of  classified  and  unclassified  but 
sensitive  information. 

The  Designated  Approval  Authority  (DAA)  is 
introduced  in  the  draft.  Most  DoD  components 
have  already  defined  and  incorporated  the 
term  Jn  their  own  implementing  regulations, 
so  updating  the  directive  on  this  issue  made 
it  current  with  the  implementing  regulations 
of  other  DoD  components. 

The  responsibilities  of  the  System  Security 
Officer  (SSO)  are  expanded  in  the  draft 
directive.  In  the  current  directive,  the  SSO 
is  not  appointed  until  an  AIS  is  operational. 
In  the  draft,  it  is  required  that  someone  be 
appointed  the  SSO  early  in  the  life  cycle  of 
a  new  AIS  to  ensure  that  security  is 
considered  during  the  design  and  development 
stages . 

As  in  the  case  of  the  DAA,  there  were  several 
other  issues  in  the  draft  directive  that  were 
updated  to  bring  the  draft  in  line  with  DoD 
implementing  regulations. 

Status .  The  draft  directive  is  currently 
being  coordinated  among  the  DoD  components 
for  their  concurrences  and  comments. 

TRUSTED  NETWORK  WIOEMMS 

Background .  The  Standards  Division  of  the 
NCSC  began  a  project  in  late  1983  to  draft 
what  were  then  known  as  Trusted  Network 
Evaluation  Criteria.  An  invitational 
workshop  was  held  in  New  Orleans  in  March, 
1985,  to  obtain  input  from  the  DoD,  from 
private  industry  such  as  vendors  and  users  or 
computer  networks,  and  from  the  academic 
community.  Using  material  produced  in  the 
workshop,  a  draft  Trusted  Network  Evaluation 
Criteria  was  developed  and  published  in  July, 
1985.  The  draft,  informally  known  as  the 
Brown  Book,  was  distributed  to  several 
hundred  reviewers  for  their  comments. 

Comments  received  from  the  reviewers  were 
extremely  disparate,  and  it  was  concluded 
that  the  Brown  Book  could  not  be  modified  to 
satisfy  the  diverse  viewpoints  of  the 
reviewers. 


The  Brown  Book  was  scrapped  and  a  different 
approach  was  taken.  A  working  group  was 
formed  to  interpret  the  DoD  Trusted  Computer 
System  Evaluation  Criteria  (TCSEC)  for 
computer  networks  and  prepare  a  draft 
guideline. 

Overview  of  the  Proposed  Guideline.  The 
Trusted  Network  Guideline  (TNG)  will  apply 
only  to  those  networks  that  can  be  thought  of 
as  having  one  trusted  network  base  (TNB) . 
There  are  other  types  of  networks,  and  thare 
are  internets  that  are  in  soma  sense  also 
networks.  These  networks  do  not  support  a 
single  TNB,  and,  therefore,  it  may  not  be 
meaningful  to  assign  a  rating  to  them  in  the 
way  that  we  could  assign  a  rating  to  a 
network  with  a  single  TNB. 

The  TNG  will  apply  only  to  those  networks 
that  provide  all  users  with  an  interface  that 
is  at  the  same  level  of  trust.  Other  net¬ 
works  should  be  connected  using  what  will  be 
called  "interconnection  rules,"  which  will  be 
provided  either  as  an  appendix  to  the  TNG  or 
as  a  separate  document. 

Tentatively,  the  TNG  will  be  comprised  of 
criteria  (from  the  Orange  Book) ,  interpre¬ 
tations  of  the  criteria  for  networks,  and 
rationale  for  the  interpretations.  New 
requirements  will  be  added  to  address 
integrity  and  denial  of  service  issues. 

These  issues  are  significantly  more  important 
for  networks  than  they  are  for  Btand-alone 
systems. 

Status.  The  draft  is  being  developed  and, 
once  the  working  group  is  satisfied  with  it, 
will  be  distributed  to  a  larger  group  of 
reviewers.  The  draft  will  then  be  revised  as 
necessary  and  published  and  reviewed  by  as 
wide  a  community  as  reviewed  the  Brown  Book. 
It  is  our  goal  to  have  a  comprehensive  draft 
document  published  by  the  end  of  this  year. 

GUIDELINE  ON  OFFICE  AUTOMATION 

Background.  The  Standards  Division  of  the 
NCSC  was  tasked  by  the  Standards  and  Guide¬ 
lines  Working  Group  of  the  Subcommittee  on 
Automated  Information  System  Security  (SAISS) 
with  developing  a  guideline  on  office 
Automation  Security.  The  goal  of  this  effort 
was  to  produce  a  document  that  would  provide 
guidance  for  all  OA  systems  in  the  Federal 
Government  that  are  used  to  process  class¬ 
ified  or  other  sensitive  information.  The 
document  that  has  resulted  from  this  effort 
is  entitled  A  Guideline  on  Office  Automation 
Security. 

intended  to  provide  guidance  to  users, 
security  officers,  procurement  officors,  and 
others  having  responsibility  for  the  security 
of  an  office  automation  system  at  some  time 
during  its  life-cycle. 
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The  guideline  is  divided  into  four  parts. 

Part  X  is  an  introduction  and  overview.  It 
contains  the  introduction,  purpose  and  scope 
of  the  guideline,  as  well  as  a  high-level 
overview  of  why  the  office  automation 
security  problem  is  different  from  other 
computer  security  problems. 

Part  XX  of  the  document  provides  security 
guidance  for  users  of  OA  systems.  The  class 
of  users  includes  secretaries,  managers, 
technical  and  non-techniaal  users,  and 
others.  Therf fore,  this  part  of  the  document 
has  been  carefully  written  to  be  under¬ 
standable  by  all  who  need  the  guidance  it 
gives . 

Part  XI  aontains  chapters  on  the  security 
responsibilities  of  OA  system  users, 
operational  security  guidance  for  stand-alone 
OA  systems,  and  operational  security  guidance 
for  connected  OA  systems. 

Part  XXX  of  the  guideline  provides  guidance 
for  OA  System  Security  Officers.  There  is  a 
chapter  that  outlines  some  of  the  security 
responsibilities  of  the  SSOs,  and  a  chapter 
that  discusses  various  threats,  vulnera¬ 
bilities  and  controls  that  they  should  be 
aware  of. 

Part  XV  of  the  guideline  gives  guidance  to 
others.  There  is  a  chapter  outlining  some  of 
the  seourity  responsibilities  of  the  organi¬ 
zation  that  owns  or  is  otherwise  responsible 
for  the  system.  There  is  a  chapter  that 
gives  guidance  to  procurement  officers  con¬ 
cerning  important  points  to  consider  when  it 
is  time  to  acquire  an  OA  system.  There  is 
also  a  chapter  on  the  secure  disposal  of  both 
the  OA  system  and  the  magnetic  storage  media 
that  ia  used  in  it. 

Xn  addition,  there  is  an  appendix  that 
provides  a  guideline  on  sensitivity  marking 
for  the  OA  system  and  its  storage  media. 

This  appendix  suggests  a  scheme  for  the 
physical  labeling  of  equipment  to  help 
prevent  accidental  compromise  of  classified 
or  other  sensitive  information. 

Status .  Drafts  of  the  guideline  have  been 
reviewed  by  members  of  the  Working  Group,  as 
well  as  by  members  and  observers  of  the 
SAISS.  It  will  be  voted  on  by  both  the  SAISS 
and  the  Subcommittee  on  Telecommunications 
Security.  If  approved,  then  the  NTISSC  will 
deaida  whether  or  not  to  release  the 
guideline  as  an  Advisory  Memorandum.  The 
guideline  should  be  available  for  public 
release  in  the  near  future. 
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PANEL 


ON 

DATABASE  MANAGEMENT  SYSTEM  SECURITY  REQUIREMENTS 


We  rely  on  databases  In  the  defense  of 
this  country,  to  support  our  financial  and 
legal  systems,  in  our  medical  and  educational 
systems,  and  even  to  receive  our  paychecks. 
Very  serious  consequences  could  result  from 
the  penetration  and/or  alteration  of  these 
systems. 

According  to  an  Ohio  University  Study  in 
the  September  9,  198 5  issue  of  Computer  & 
Software  News ■  seventy  percent  of  the  top 
videotex  and  database  service  firm  executives 
considered  unauthorized  access  to  be  a 
significant  problem.  Ten  percent  reported 
that  tampering  occurs  on  a  weekly  or  more 
frequent  basis.  Another  ten  percent  reported 
that  tampering  incidents  oacur  monthly. 
Thirty-two  percent  cited  other  intervals  of 
frequency . 

Since  the  1982  summer  Study  on 
Multilevel  Data  Management  Security,  several 
operating  system  products  have  appeared  on 
the  Evaluated  Products  List  and  many  more 
candidates  are  being  evaluated.  Today, 
however,  an  unsecured  database  management 
system,  placed  on  a  trusted  operating  system, 
produces 

an  overall  system  where  the  data  is  poorly 
protected. 

A  primary  research  emphasis  of  the 
National  Computer  Security  Center  has  been 
the  development  of  secure  operating  systems. 
With  the  first  of  these  products  developed, 
we  now  turn  our  attention  to  an  even  more 
difficult  area:  database  security.  The 
primary  guidance  that  the  Center  and  vendors 


nave  had  on  secure  data  management  has  come 
from  the  Summer  Study  report,  which  details 
near-  and  long-range  goals  and  objectives  for 
secure  data  management  research.  Additional 
input  has  been  obtained  from  the  Center's 
technical  review  group  and  from  the  recent 
workshop  on  database  security. 


This  panel  will  review  the  validity  of 
the  findings  of  the  Summer  study,  open  a  new 
forum  for  discussion  on  what  the  user 
community  sees  as  their  current  and  future 
requirements  for  secure  data  management,  and 
present  a  brief  synopsis  of  database  security 
research  in  progress.  It  would  serve  as  a 
kickoff  to  a  general  data  call  planned  by  the 
Centor's  Secure  Database  Researah  and 
Development  Branch  to  determine  its  direction 
in  database  security  research. 


Panel  chair: 

Dr.  John  R.  Campbell,  National  Computer 
Security  Center 


Panel  Members: 

Dorothy  E.  Denning,  SRI  International 

Kenneth  Eggers,  MITRE 

Roger  Schell,  Gemini  computers,  Inc. 

Charles  J.  Testa,  Infosyatomo  Technology, 
Ino. 
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PANEL  DISCUSSION 


NCSC  AND  VERIFICATION 


Formal  Specification  and  Verification 
are  important  technologies  in  the 
production  of  secure  computer  systems.  As 
development  of  A1  (and  beyond  Al)  systems 
increase,  greater  demands  will  be  placed 
on  the  automated  verification  tools  and 
the  developers  and  maintainers  who  support 
their  use. 

The  National  Computer  Security  Center 
(NCSC)  has  made  a  commitment  to  support 
formal  verification.  What  does  such  a 
commitment  mean,  and  what  is  the  NCSC 
doing  to  fulfill  that  commitment? 

The  primary  focus  of  this  panel 
discussion  is  to  identify  the  role  and 
commitment  of  the  Canter  concerning  the 
formal  specification  and  verification 
technology.  The  discussion  will  include 
the  following  topics: 

a.  The  need  for  verification 
(introduction) . 

b.  The  Product  Evaluator's 
Verification  Working  Group.  This  working 
group  was  created  to  help  evaluators  with 
verification  issues  concerning  Al  or 
bayond-Al  evaluations.  A  description  of 
the  working  group's  charter  and  progress 
are  presented. 


c.  Endorsed  tools.  Questions 
such  as  "What  does  endorsed  mean?"  and 
"How  can  a  verification  system  be  added  or 
deleted  from  the  endorsed  tools  list 
(ETL) ?"  are  discussed. 

d.  Future  endeavors  (1  year) . 

e.  Milestones.  The  center  has 
been  in  the  forefront  of  verification 
activities.  Such  activities  are 
highlighted. 

f.  Future  technology.  Thoughts 
of  where  verification  technology  will  be 
in  5  years. 


The  panelists  are  representatives 
from  all  offices  within  the  NCSC  and  two 
recognized  verification  experts  outside  of 
the  NCSC.  The  format  for  this  panel 
session  is  to  have  each  key  panelist  talk 
for  approximately  10  minutes,  after  which 
the  panel  is  open  to  questions  from  the 
floor. 
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PANEL  DISCUSSION 


Using  the  Criteria  in  Acquisitions 


Incorporating  trusted  system  computer  security  related 
requirements  into  acquisition  programs  is  a  difficult  task  faced 
by  managers  procuring  trusted  systems.  The  evolution  of  the 
Department  of  Defense  Trusted  Computer  Systems  Evaluation 
Criteria  from  a  guideline  (CSC-STD-001)  to  a  Department  of 
Defense  standard  (5200.28-STD)  will  certainly  add  to  the  number 
of  acquisitions  requiring  trusted  systems.  Thus,  this  panel  is 
geared  to  provide  the  audience  with  information  about  real  world 
trusted  system  acquisitions  and  how  to  integrate  security, 
acquisition,  and  program  requirements.  The  panelist  are  key 
players  involved  in  program  acquisitions  ranging  from  class 
B1  -  Al.  The  topics  include: 

-  Computer  Security  Acquisition  Management 

-  Procurement  Guidelines  for  Multi-level  Systems 

-  Applying  the  Procurement  Guidelines  at  Class  B1 

-  Inter service/ Agency  Automated  Message  Processing 

Exchange  (I-S/A  AMPE)  Experience 

-  The  BLACKER  Program  and  the  Criteria 

-  The  FORSCOM  SECURITY  MONITOR  (FSM)  Lessons  Learned 

The  panelist  are  Mrs.  Suzanne  O’Connor,  Standards  and 
Products  Office  of  the  National  Computer  Security  Center  (NCSC) ; 
Miss.  Leslee  O'Dell,  Special  Projects  Office  of  the  NCSC;  Mr. 
Gregory  Elkmann,  Automated  Information  System  Evaluation  Office 
of  NSA;  Mr.  H.  0.  Lubbes,  Space  and  Naval  Warfare  Systems 
Command;  and  Captain  William  Collier,  Automated  Information 
System  Evaluation  Office  of  NSA.  The  panel  chairman  is  Major 
Donald  Baker,  Technical  Support  Office  of  the  NCSC. 
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AN  ECONOMICALLY  FEASIBLE  APPROACH  TO  CONTINGENCY  PLANNING. 


Robert  H.  Courtney,  Jr. 
Robert  Courtney,  Inc. 
Box  836 

Port  Ewan,  New  York  12466 
914-338-2525 


INTRODUCTION 
What  is  a  Contingency  Plan? 

A  contingency  plan  describes  the  appropriate 
response  to  any  situation  which  jeopardizes 
the  safety  of  data  or  of  data  processing  and 
communications  facilities  to  a  degree  that 
threatens  meaningful  harm  to  the  organi¬ 
zations  supported  by  those  data  and  facili¬ 
ties.  A  contingency  plan  is  not  a.  book;  it  is 
an  action  plan. 

The  threatening  situation  need  not  bo  a 
disaster  which  causes  extensive  physical 
damage.  The  disruption  may  cause  no  damage  at 
all  to  the  physical  facility  as  is  often  the 
case  with  a  chemical  spill  which,  by  forcing 
the  evacuation  of  personnel,  stops  data 
processing  activities.  In  fact,  the  economic 
feasibility  of  a  contingency  plan  may  well 
lie  in  its  ability  to  contain  small  problems 
at  small  cost  as  well  as  providing  the 
ability  to  fare  through  the  total  loss  of  a 
physical  facility. 

The  threats  to  be  anticipated  in  devising  the 
contingency  plan  need  only  be  sufficiently 
great  in  both  the  magnitudes  of  the  potential 
losses  and  in  their  probability  of  occurrence 
to  justify  the  preparation  of  plans  to  avoid 
those  losses  if  a  course  of  action  which 
costs  significantly  less  than  the  anticipated 
loss  can  be  devised. 

It  is  regrettable  that  the  term  "disaster 
recovery  plan"  has  become,  for  many,  synony¬ 
mous  with  "contingency  plan" .  It  seems 
somewhat  more  rational  to  consider  the 
contingency  plan  to  be  a  disaster  avoidance 
plan  rather  than  a  way  of  recovering  from  a 
disaster.  Most  of  our  data  processing  disas¬ 
ters  become  such  only  because  we  are  not 
prepared  to  cope  with  what  might  have  been 
only  an  inconvenience  if  we  had  prepared 
properly. 

Who  Needs  Them? 


Any  organization  which  is  susceptible  to 
significant  harm  if  it  loses  its  data  or  the 
facilities  associated  with  their  use  needs  a 
plan  with  which  to  respond  to  reasonably 
anticipatable  disruptions  to  normal  data 
processing  operations.  These  can  include 
labor  problems  as  well  as  earthquakes, 
leaking  roofs  as  well  as  floods,  gross 
mistakes  by  loyal  employees  and  bombs  by 
terrorists,  area-wide  losses  of  power  and 
vital  communications  lines  cut  by  back-hoes. 

The  losses  which  mount  as  a  consequence  of 
system  outages  vary  widely  with  the  nature  of 
supported  organizations.  Some  major  organiza¬ 
tions  will  not  be  seriously  hurt  with 


downtimes  as  long  as  a  week.  Others  will 
suffer  meaningful  losses,  amounting  to  as 
much  as  two-thirds  gross  revenue,  starting 
within  minutes  of  loss  of  system  support. 

Who  Has  Them? 


Truly  workable,  fully  tested,  economically 
feasible  contingency  plans  are  in  place  for 
only  a  small  percentage  of  the  data  process¬ 
ing  mainframe  installations.  There  are  no 
untested  but  workable  contingency  plans.  Such 
tests  always  reveal  deficiencies  to  be  fixed. 

It  is  our  belief,  based  upon  many  discussions 
of  the  subject  with  DP  management  and  others, 
that  the  principal  reason  for  the  absence  of 
good  contingency  plans,  at  least  in  the 
private  sector,  but  to  a  lesser  degree  in  the 
public  sector  because  of  the  many  complicat¬ 
ing  factors  there,  is  the  continuing  belief 
by  much  of  the  DP  management  that  workable 
plans  are  far  too  costly  or  are,  in  reality, 
infeasible.  Other  important  and  more  urgent 
issues  do  divert  management  attention  from 
contingency  planning  and  other  security 
related  considerations  as  well,  but  the 
principal  barrier  seems  to  be  lack  of  confi¬ 
dence  that  a  truly  workable  plan  can  be 
configured.  Until  more  DP  directors  are 
batter  informed  about  the  economic  feasibil¬ 
ity  and  workability  of  contingency  plans, 
this  situation  will  not  change. 

Our  goal  here  is  to  describe  an  approach  to 
contingency  planning  which  is  clearly  work¬ 
able  in  many,  but  certainly  not  all,  organiza¬ 
tions  . 


THE  MAJOR  COMPONENTS 

We  are  addressing  here  contingency  plane  for 
data  processing,  including  communications, 
data  acquisition,  storage,  and  presentation. 
Of  no  less  importance,  but  not  within  the 
scopa  of  this  paper,  are  the  contingency 
plans  for  the  critical  dependencies  which  are 
ndt  DP  related.  Preservation  of  the  ability 
to  take  orders  and  bill  customers  may  lack 
importance  if  there  is  no  means  of  making 
shippable  product. 

The  essential  components  of  a  complete 
contingency  plan  a  ■  theses 

1.  Emergency  Response  Plan.-  A  plan  to 
respond  promptly  and  well  to  a  potential 
disruption  so  as  to  limit  the  damage  is 
highly  desirable.  Fire  extinguishers  are 
almost  worthless  if  no  one  knows  how  to  use 
them.  In  this  category,  then,  are  the  things 
which  should  be  done  as  soon  as  there  is  an 
awareness  of  a  potential  problem  which  might 
result  in  the  invocation  of  the  contingency 
plan. 
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2.  Back-Up  Flan.-  The  back-up  plan  provides 
the  ability  to  conduct,  by  alternate  means, 
the  critical  data  processing  workload.  The 
critical  workload  is  that  portion  of  the 
workload  which  will  generate  serious  loss  if 
disrupted  for  a  period  exceeding  two  weeks. 
See  our  comments  later  here  on  the  selection 
of  the  two  week  period. 

3.  Recovery  Plan.-  The  Recovery  Plan  guides 
the  return  to  full  and  normal  data  processing 
capability. 

All  three  plans  must  be  considered  because 
all  aro  important,  but  the  first  two,  the 
emergency  response  and  back-up  plans,  are  the 
most  difficult  to  put  in  place  and,  usually, 
are  the  most  urgently  needed.  There  is  rarely 
any  significant  overlap  of  the  three  categor¬ 
ies.  This  paper  is  oriented  primarily  toward 
tho  provision  of  economically  feasible 
back-up  capabilities. 

THE  ALTERNATIVES 

Several  different  approaches  to  the  provision 
of  back-up  capability  can  be  considered.  They 
are  not  all  equally  workable.  These  should  be 
considered  only  under  some  quite  exceptional 
circumstances.  The  principal  alternatives, 
then,  are  these: 

Doing  Nothing. 

There  are  a  few  organizations  quite  dependent 
upon  computer-based  systems  which  will  suffer 
but  little  loss  If  they  are  without  that  data 
processing  support  for  two  weeks  or  so.  Such 
loss  as  they  might  encounter  if  they  cannot 
run  their  work  will  be  quite  small  in  compar¬ 
ison  with  the  coat  of  a  back-up  capability. 
Those  charged  with  contingency  planning 
should  consider  the  highly  desirable  possibil¬ 
ity  that  their  respective  organizations  any 
be  in  this  category. 

It  is  not  wholly  uncommon  to  encounter  the 
absence  of  need  for  back-up  in  headquarters 
operations  where  computers  are  used  primarily 
for  planning  and  higher  level  awareness  and 
control  purposes  and  where  accounting, 
payroll,  order  entry,  inventory  management 
and  other  such  time-dependent  tasks  are 
provided  for  the  enterprise  by  DP  shops  in 
the  operating  divisions.  Note  that  these 
other  DP  shops  do  need  back-up  capabilities. 

Mutual  Aid  Agreements. 

External .  Arrangements  made  with  other, 
unaffiliated  organizations  to  provide  back-up 
data  processing  support  by  deferring  some  of 
the  supporting  company's  less  critical  work 
can  work  under  some  circumstances.  It  is 
usually  fairly  easy  to  arrive  at  some  inform¬ 
al  agreement  of  this  typo  with  other  organiza¬ 
tions.  It  is  more  difficult  to  establish 
formal  written  agreements  which  are  workable. 
It  is  usually  quite  difficult  to  establish 
such  mutual  aid  agreements  involving  ade¬ 
quate,  periodic  tests  of  that  back-up.  In 
general,  and  as  we  stated  rather  forcefully 
above,  untested  back-up  plans  do  not  work. 


These  arrangements  increase  in  workability 
under  the  following  circumstances: 

1.  When  there  are  unused  shifts 
available  at  the  back-up  facility 
so  that  less  work,  if  any,  is 
displaced  in  the  supporting  com¬ 
pany. 

2.  When  the  work  to  be  backed  up  is 
primarily  vanilla  batch  or  with 
limited  use  of  in-dial  ports  only. 

3.  When  the  CPU's  are  relatively 
small. 

4.  When  the  need  for  back-up  is  such 
that  delays  of  a  few  days  will  not 
be  very  costly. 

5.  When  the  mutually  supportive 
organizations  are  in  the  same 
industry  areas;  e.g.,  commercial 
banking.  That  two  companies  are 
possible  competitors  is  often  an 
impediment,  but  usually  not  so 
great  a  problem  as  a  complete  lack 
of  appreciation  of  what  the  other 
is  trying  to  do  as  when  they  are  in 
different  businesses. 

6.  When  the  two  companies  are  of 
roughly  the  same  size. 

None  of  the  above  factors  are  without  notable 
exceptions,  but  they  should  provide  some 
useful  guidance  in  considering  a  mutual  aid 
agreement  with  another  organization. 

The  most  useful  observation  we  can  make  here 
about  mutual  aid  agreements  between  wholly 
unaffiliatsd  organizations  is  that  they  very 
rarely  work  when  they  are  needed. 

Internal,  The  workability  of  mutual  aid 
agreements  between  groups  with  some  organiza¬ 
tional  affinity  is  dependent  upon  many 
factors.  The  more  prominent  of  those  factors 
are  those: 

1.  The  strength  of  the  stated  desire 
of  the  common  management  that  the 
respective  organizations  arrange 
such  back-up  support, 

2.  The  quality  and  the  degree  of 

realism  reflected  in  the  back-up 
plan. 

3.  The  conduct  of  wholly  realistic 

tests  of  the  back-up  capability. 

4.  The  similarity  of  the  mutually 

supportive  systems. 

5.  Tho  simplicity  of  the  required 

communications  support . 

6.  The  physical  proximity  of  the  two 
sites  -•  provided  that  they  are  not 
so  close  as  to  be  affected  by  the 
same  source  of  disruption. 
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7. 


The  availability  of  time  to  correct 
deficiencies  in  the  back-up  support 
after  disruption  and  before  losses 
mount  intolerably. 

Many  other  things  can  be  listed,  but  these 
deserve  careful  consideration  before  this 
option  is  elected. 

The  greatest  single  factor  in  the  workability 
of  this  arrangement  is  the  ability  and 
willingness  of  the  common  management  to 
require  the  provision  of  fully  tested  back¬ 
up.  Other  factors  are  very  important,  but 
this  one  is  usually  key. 

Open  Hot  Site. 

An  open  hot  site  is  a  data  processing  facili¬ 
ty  operated  for  profit  by  making  available  to 
otherwise  unaffiliated  companies  a  site  on 
which  they  can  conduct  their  data  processing 
after  loss  of  the  use  of  their  own  facility. 
Those  are  characterized  by  the  facilities  of 
COMDISCO  and  SUNGARD. 

Monthly  subscription  rates  are  paid  to 
preserve  the  ability  to  test  the  back-up 
plans  and,  when  necessary  and  on  payment  of 
additional  fees,  to  declare  an  emergency  and 
move  the  <  itical  workload  onto  this  alter¬ 
nate  facility. 

This  arrangement  is  indeed  quite  workable  for 
a  number  of  companies,  but  it  is  far  from  a 
universal  solution.  It  can  be  a  partial 
solution  for  some  banks,  for  example,  but  it 
will  not  solve  the  problem  of  data  capture, 
including  the  proof  operations,  so  essential 
to  curtailing  losses  through  disruption  to 
demand  deposit  operations. 

An  analysis  of  the  economic  feasibility  of. 
the  open  hot  site  as  back-up  for  any  specific 
facility  must  include  careful  and  quantita¬ 
tive  consideration  of  the  speed  with  which 
key  data  processing  functions  must  bo  restor¬ 
ed.  The  feasibility  of  this  approach  clearly 
increases  with  the  length  of  time  available 
to  move  people  and  data,  to  fix  unanticipated 
problems,  and  to  adapt  the  hot  site  communi¬ 
cations  facilities  to  the  peculiar  needs  of 
the  using  organization.  The  cost  of  repeated 
teats  at  a  geographically  remote  location 
must  also  be  considered  in  evaluating  this 
alternative. 

Although  it  may  be  argued  that  such  should 
not  be  the  case ,  we  have  seen  too  many 
instances  in  which  recovery  at  the  hot  site 
has  been  deferred  for  an  inordinately  long 
period  while  attempts  are  made  to  recover  at 
the  primary  location  to  avoid  paying  the  fees 
for  declaring  an  emergency  or  because  there 
is  fear  that  the  contingency  plan  may  not 
actually  work.  Further,  if  there  is  some 
reasonable  possibility  of  a  prompt  recovery 
at  the  primary  site,  prudent  management  will 
be  reluctant  to  send  the  best  people  avail¬ 
able  to  the  hot  site,  as  will  be  needed  to 
establish  operations  in  a  different  location, 
when  it  is  clear  that  operations  cannot  be 
re-established  at  home  without  those  best 
people.  This  is  a  difficult  dilemma  for  the 


DP  Director  to  resolve  when  he  is  faced  with 
the  plethora  of  problems  normally  encountered 
when  a  busy  facility  is  suddenly  and  serious¬ 
ly  disrupted. 

Closed  Hot  Site. 

A  closed  hot  site  is  a  facility  which  is 
owned  by  a  consortium  or  which  was  otherwise 
constructed  for  a  specific  set  of  companies 
to  satisfy  some  less  than  highly  general  need 
for  back-up  capability.  Such  a  facility  might 
provide  proof  machines  and  operators  and 
check  sorters  for  a  group  of  banks.  It  might 
provide  unusually  rapid  availability  of 
back-up  for  organizations  which  encounter 
serious  losses  beginning  with  the  first 
minute  of  facility  outage. 

These  facilities  are  rare  primarily  because 
of  the  heavy  requirements  for  a  peculiar 
combination  of  entrepreneurial  spirit, 
salesmanship,  technical  strength,  and  quite 
substantial  investment  (by  the  participating 
companies)  needed  to  get  them  to  an  operation¬ 
al  state.  They  can  be  a  highly  satisfactory 
way  of  satisfying  the  back-up  needs  of 
enterprises  which  cannot  afford  to  be  down 
for  even  very  short  periods,  but  the  costs 
are  significantly  greater  than  those  seen 
with  open  hot  sites.  These  higher  costs  are 
justified  only  when  they  are  fully  displaced 
by  sum  of  the  losses  avoided  by  this  approach 
and  the  continuing  availability  of  the 
facility  to  the  participating  companies  for 
rehearsal  of  back-up  plans  and  for  app) ica- 
tion  development  and  test. 

This  approach  is  definitely  not  the  way  of 
the  future  for  very  many  organizations.  It  is 
very  good  for  those  who  need  it,  but  it  will 
not  be  economically  feasible  for  very  many 
others.  In  some  of  those  organizations  for 
which  it  would  be  the  correct  approach,  the 
DP  management  will  not  find  it  acceptable  to 
ask  the  corporate  management  for  the  neces¬ 
sary  funds  to  participate  in  such  a  consorti¬ 
um. 

Split  Sites. 

Later  in  this  paper  we  discuss  the  determina¬ 
tion  of  the  size  of  the  truly  critical 
workload  in  a  DP  mainframe  facility. 

For  our  immediate  purposes  here,  it  is 
sufficient  to  say  that  it  is  very  rare  to 
encounter  a  conventional  data  processing 
facility  supporting  a  multiplicity  of  appli¬ 
cations  on  a  mainframe  where  the  truly 
critical  workload  approaches  50%  of  the 
total.  Our  definition  of  critical  workload  is 
that  portion  of  the  workload  which,  if 
discontinued  for  two  weeks,  would  result  in 
serious  loss,  not  just  inconvenience,  to  the 
enterprise.  Most  commonly,  if  a  reasonably 
objective  evaluation  is  made  of  critical 
workload,  it  will  be  less  than  20%  of  the 
total. 

We  have  found  it  generally  quite  feasible  to 
return  to  a  reasonable  semblance  of  normal 
operations  within  two  weeks  of  even  a  major 
facility  loss.  For  this  reason  we  use  the 
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two-week  period  in  our  definition  of  critical 
workload. 

If  the  critical  workload  on  a  facility  is 
significantly  less  than  50%  of  the  total, 
then  it  is  possible  to  consider  splitting  an 
existing  site  into  two  physically  separate 
parts  either  of  which  is  large  enough  to 
carry  the  critical  workload.  At  least  theo¬ 
retically,  this  does  not  require  any  increase 
in  data  processing  capacity.  In  actual 
practice,  that  is  not  quite  correct. 

However,  with  a  split  site,  if  either  is 
lost,  the  other  can  carry  the  critical 
workload  after  shedding  that  portion  of  the 
non-critical  workload  it  was  carrying  before 
loss  of  that  other  facility. 

It  is  our  contention  that,  while  other 
approaches  to  back-up  are  sometimes  workable, 
the  most  broadly  applicable,  economically 
feasible  approach  to  backing  up  critical 
workloads  on  mainframes  is  the  split-site 
arrangement. 

Standby  Facilities, 

We  noted  above  that  it  is  rarely  possible  to 
provide  economic  justification  for  a  whole 
standby  facility  which  does  nothing  until  the 
primary  one  is  lost.  It  is  possible  to 
compose  a  scenario  in  which  the  consequences 
of  losing  a  facility  are  so  dire  as  to 
provide  such  justification.  This  is  most 
commonly  true  with  smaller,  dedicated  ma¬ 
chines  such  as  those  driving  automated 
warehouses. 

In  the  whole  population  of  computers,  there 
are  enough  situations  where  dedication  of 
otherwise  unused  back-up  facilities  are 
justified  that  that  category  cannot  be 
excluded  from  any  reasonably  comprehensive 
list  of  alternative  approaches. 

Data  Servicers. 

Many  organizations  would  be  well-served  in 
any  attempt  to  reduce  or  eliminate  the 
critical  workload  to  consider  taking  all  or  a 
portion  of  it,  depending  on  its  nature,  to  a 
data  servicer  such  as  ADP  or  McAuto,  They  not 
only  might  substantially  reduce  the  cost  of 
operations  such  as  payroll,  they  can  also 
have  advantage  of  the  extensive  facilities  of 
the  larger  organizations  in  that  business  to 
assure  a  high  probability  of  the  continued 
support  of  those  delegated  functions.  In 
general,  however,  the  time  to  place  the  work 
with  the  data  servicers  is  before  and  not 
after  disruption  to  your  facilities. 

A  complete  discussion  of  the  several  reasons 
for  taking  payroll  and  some  other  common 
business  functions  to  outBide  specialists  is 
somewhat  beyond  the  scope  of  this  paper,  but 
the  reader  should  give  it  appropriate  consid¬ 
eration. 

Combinations  of  Alternatives. 

It  is  readily  apparent  that  some  combination 
of  the  different  alternatives  may  best  suit 
the  needs  of  very  large  organizations  and 


even  a  few  ot  the  very  small  ones.  For 
example,  a  bank  may  well  consider  taking  its 
payroll  to  ADP,  using  an  open  hot  site  for 
its  mainframe  back-up,  and  joining  a  consor¬ 
tium  for  proof  and  sorting  operations.  Many 
other  equally  plausible  examples  can  be 
cited. 

THE  CRITICAL  WORKLOAD. 

What  is  the  Critical  Workload? 

Earlier  here  we  said  that  the  critical 
workload  is  that  portion  of  the  total  work¬ 
load  which  would  cause  serious  loss  if  it 
could  not  be  conducted  for  periods  of  up  to 
two  weeks.  The  two  weeks  is  fairly  arbitrary 
but,  in  reality,  most  companies  do  manage 
substantial  recovery  of  their  data  processing 
operations  in  that  time  even  when  there  has 
been  catastrophic  loss  of  a  major  facility. 
If  the  two-week  interval  seems  inappropriate 
to  any  particular  environment,  it  is  quite 
reasonable  to  pick  some  longer  or  shorter 
period,  although  much  shorter  might  be  quite 
risky. 

Another  perspective  on  the  problem  might 
suggest  that  the  critical  workload  is  that 
portion  of  the  total  which,  if  it  is  inter¬ 
rupted,  would  generate  losses  great  enough  to 
provide  economic  justification  of  a  back-up 
capability  which  would  obviate  such  losses. 
This  view  of  things  is  not  correct  because  is 
suggests  an  assessment  of  criticality  based 
on  cost  of  back-up.  The  desirability  of 
avoiding  loss  does  not  change  with  the 
feasibility  of  avoiding  it. 

All  of  the  potential  losses  which  would 
result  from  an  outage  should  be  compiled,  not 
just  those  which  can  be  obviated  by  some 
current  notion  of  the  nature  of  an  appropri¬ 
ate  back-up  capability.  Only  whan  those  are 
available  will  it  bo  possible  to  configure  a 
back-up  plan  which  is  sufficiently  detailed 
to  be  workable.  When  these  potentially 
avoidable  losses  have  been  compiled,  then  we 
can  evaluate  the  various  approaches  available 
to  us  for  providing  a  back-up  capability  and 
select  the  combination  which  displaces  the 
greatest  potential  loss  for  the  least  cost. 

EAL  -  (Cost) (Probability  of  Occurrence) . 

The  Expected  Annual  Loss  (EAL)  which  is  used 
to  justify  backing  up  a  data  processing 
function  or  not  should  be  evaluated  in  terms 
of  net  just  the  dollar  consequences  of  an 
undesirable  event  but  also  the  probability 
that  it  will  happen.  It  is  not  reasonable  to 
base  a  contingency  plan  on  an  assessment  of 
consequences  alone;  consideration  must  also 
be  given  the  probability  (or  frequency)  of 
encountering  the  interruption.  It  is  clear 
that  the  anticipated  loss  must  be  the  result 
of  consideration  of  both  the  damage  done  and 
the  chance  of  encountering  the  problem. 

When  doing  a  risk  assessment  for  contingency 
planning  purposes,  it  is  usually  far  easier 
to  assess  the  consequences  of  a  disruption 
than  it  is  to  judge  the  probability  of 
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encountering  the  problem.  Fortunately,  quite 
gross  estimates  of  which  we  can  be  reasonably 
certain  are  usually  good  enough.  No  attempt 
should  be  made  to  refine  data  beyond  the 
point  where  the  improved  precision  does  not 
make  a  difference  in  what  we  do.  Only  when  we 
realize  that  the  determinant  for  a  course  of 
action  lies  in  the  area  of  uncertainty 
between  the  upper  and  lower  bounds  of  the 
value  we  assign  a  parameter  are  we  justified 
in  expending  the  effort  to  further  refine 
those  data.  Distinctions  without  differences 
are  useless;  and  for  there  to  be  a  differ¬ 
ence,  a  change  has  to  make  a  difference. 

We  have  found  fairly  consistently  that  we  are 
rarely  hampered  by  difficulty  in  estimating 
probabilities  of  occurrence.  Far  more  often 
than  not,  when  we  take  the  probability  to  a 
level  so  low  that  we  are  quite  comfortable 
with  it,  the  consequences  are  sufficiently 
large  to  provide  adequate  justification  of 
corrective  measures.  This  should  not  be  too 
surprising  because  the  things  with  the  most 
dire  consequences  usually  happen  with  the 
lowest  frequencies  -  otherwise  the  world 
would  not  be  habitable.  On  the  other  hand, 
small  problems  often  happen  with  frequencies 
so  high  that  they  rival  or  exceed  the  EAL  of 
the  catastrophes. 

If,  for  a  particular  problem,  we  cannot 
arrive  at  an  estimate  of  probability  (or 
consequences)  in  which  we  have  adequate 
confidence,  it  is  often  best  to  simply  defer 
further  consideration  until  later.  Quite 
frequently,  the  appropriate  corrective  action 
will  be  cost- justified  by  some  other  problem 
which  is  more  readily  assessable.  If  that 
does  not  happen,  then  we  must  do  the  addition¬ 
al  work  required  to  further  refine  our  data. 

In  conducting  a  risk  assessment,  a  small 
amount  of  common  sense  far  outweighs  complex 
methodologies.  We  once  encountered  such  blind 
obeisance  to  a  flawed  risk  assessment  method¬ 
ology  that,  in  a  prioritized  list  of  critical 
data  processing  tasks  for  a  major  manufactur¬ 
ing  company,  paying  suggestion  awards  was 
ranked  first  and  higher  than  accepting 
orders,  shipping  product,  invoicing,  receiv¬ 
ing  payment,  and  getting  out  the  payroll. 

Who  Determines  the  Critical  Workload? 

Involvement  of  Functional  Area  Managers.  Our 
experience  has  been  that  determination  of  the 
critical  workload  by  the  information  systems 
personnel  working  s.lons  and  not  in  close 
cooperation  with  the  managements  of  the 
respective  functional  areas  does  not  work. 
The  DP  people  almost  never  have  the  depth  of 
understanding  of  the  need  of  the  enterprise 
for  the  proper  functioning  of  each  of  the 
essential  components  to  the  extent  that  they 
can  offer  a  quantitative  evaluation  of  the 
cost  of  their  interruption.  All  too  often, 
they  don't  know  that  they  don't  know  and,  as 
a  consequence,  make  gross  and  seriously 
erroneous  estimates  of  the  tolerance  of  the 
organization  to  specific  problems.  Their 
assessment  of  the  importance  or  criticality 
of  particular  functions  as  often  reflects  the 
strengths  of  the  personalities  of  the  persons 


from  that  area  with  whom  they  have  been 
working  as  it  does  the  real  situation. 

Importance  of  Policy  Statement.  We  have 
almost  always  found  It  more  dTfficult  to 
achieve  the  involvement  of  the  functional 
area  managers  in  any  planning  for  computer- 
related  security,  including  contingency 
planning,  in  the  absence  of  a  strong  policy 
statement  issued  by  the  chief  executive 
officer.  The  policy  statement  should  make 
specific  assignment  to  functional  managers  of 
direct  responsibility  for  the  safety  of  data 
and  the  means  of  processing  them.  The  DP 
management  should  have  custodial  responsibil¬ 
ity  for  data  and  an  obligation  to  extend  to 
the  data  and  the  processing  means  such 
safeguards  as  may  be  required  to  contain  the 
concerns  of  tue  managements  of  the  directly 
responsible  functional  areas.  The  workability 
of  this  arrangement  is  greatly  improved  if 
the  cost  of  security  as  defined  by  the 
functional  managers  is  charged  back  to  them. 
This  provides  an  incentive  for  them  to 
balance  their  concern  for  data  security,  for 
which  they  are  held  accountable  by  a  proper 
policy  statement,  against  the  cost  of  provid¬ 
ing  it  so  as  to  make  certain  that  no  more  is 
spent  protecting  data  than  it  would  cost  to 
leave  it  unprotected. 

Questionnaires  versus  Interviews.  We  know  of 
no  paper  survey  of  computer  security  matters 
with  other  than  extremely  limited  scope,  such 
as  which  access  control  method  has  been 
procured,  which  has  yielded  data  which  are 
both  accurate  and  useful.  It  is  far  easier  to 
acquire,  by  proper  questionnaire  design,  data 
which  seem  useful  than  it  ia  data  which  are 
accurate.  For  example,  there  was  in  the 
Department  of  Defense  a  contingency  planning 
questionnaire  which  asked,  "Ia  your  system  is 
subject  to  acts  of  God?"  Wc  never  saw  that 
answered  by  other  than  a  "No". 

A  major  problem  with  paper  surveys  in  the 
computer  security  area  is  that  the  nmouht  of 
explanatory  text  which  must  accompany  the 
questions  so  badly  burdens  the  task  of 
preparing  the  surveys  and  answering  them  that 
either  the  writing  or  the  reading  (or  both) 
of  that  material  is  too  often  neglected. 

We  have  found  eyeball-to-eyeball  interviews 
with  key  managers  of  functional  areaB  by  far 
the  most  satisfactory  and  least  time-consum¬ 
ing  approach  for  everyone  concerned.  The 
skilled  interviewer  should  be  accompanied  by 
a  person  from  the  DP  area  -  preferably,  the 
person  who  will  be  charged  with  maintaining 
the  contingency  plan  after  its  preparation  - 
so  as  to  provide  learning  for  him  in  the 
conduct  of  those  interviews.  With  ouch  an 
arrangement,  it  is  usually  relatively  easy  to 
roach  agreement  between  the  contingency 
planners  and  the  functional  managers  as  to 
the  direct  and,  very  importantly,  indirect 
costs  of  losing  data  or  the  processing  means 
as  a  function  of  the  duration  of  such  loss. 
As  we  noted  above,  the  frequency  or  probabil¬ 
ity  of  occurrence  may  be  a  little  more 
difficult,  but  it  is  not  an  overwhelming 
burden. 
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THE  SPLIT-SITE  APPROACH 


The  roost  commonly  encountered  major  problems 
in  achieving  and  retaining  a  truly  workable 
back-up  plan  are  these: 

1.  Identifying  the  critical  workload. 
Hot  only  must  it  be  initially 
identified,  it  must  be  continually 
assessed  as  new  applications  evolve 
and  as  the  organization's  priori¬ 
ties  change. 

2.  Assuring  suitably  prompt  availabil¬ 
ity  of  adequate  computer (s)  when 
they  are  needed. 

3.  Establishment  of  enough  of  the 
normally  required  communications 
network  to  provide  adequate  limp- 
along  capability. 

4.  Conducting  tealistic  tests  of  the 
contingency  pran  in  the  face  of 
opposition  to  the  cost  of  the 
tests,  to  the  disruption  to  non-cri- 
tical  workload  and  to  the  potential 
for  disruption  to  the  critical 
workload. 

5.  Assuring  availability  of  data.  Kith 
the  rapidly  growing  size  of  some 
data  bases,  this  problem  is  becom¬ 
ing  increasingly  severe  if  only 
because  of  the  time  and  costs 
required  to  unload  and  load  the 
amount  of  data  required  to  support 
the  critical  workload.  Planning 
and  assuring  the  availability  of 
back-up  data  has  become  an  impor¬ 
tant  and  iairly  costly  part  of  good 
systems  management.  It  is  wholly 
essential  to  workable  contingency 
plans . 

6.  Assuring  the  availability  of  the 
skill  levels  required  to  respond 
promptly  to  a  need  to  back-up  the 
critical  tasks  and  to  phase  off¬ 
line  gracefully  the  non-cr  i.tical 
tasks. 

7 .  Maintenance  of  management  support 
for  contingency  planning. 

8.  Preservation  of  an  awareness  on  the 
part  of  planners  and  developers 
that  ease  and  cost  of  back-up  and 
recovery  should  be  weighed  along 
with  all  of  the  other  operable 
factors  when  planning  new  applica¬ 
tions  and  the  refurbishing  of  old 
ones. 

The  list  above  is  not  necessarily  in  priority 
sequence.  The  relative  importance  of  these 
things  will  vary  with  the  organization. 

Now,  given  a  wide  variety  of  candidate 
approaches  to  back-up,  most  of  which  were 
listed  earlier  (with  notable  and  generally 
unworkable  exceptions,  such  as  dedicated  and 
unused  floor  space  v  ith  no  OP  hardware)  and 


given  these  more  common  difficulties,  we  must 
pick  an  approach  that  promises  the  greatest 
potential  workability.  More  often  than  not, 
it  is  the  split  site. 

While  the  split  site  is  most  often  the  most 
workable  approach  to  back-up,  it  1b  not 
necessarily  the  approach  chosen  even  when  it 
is  the  most  appropriate.  Too  often  there  is 
an  unwillingness  to  solicit  management 
support  for  any  approach  which  will  have 
significant  cost,  even  when  it  is  cost- justi¬ 
fied.  If  the  cost  will  require  a  diversion  of 
resource  which  would  otherwise  be  available 
to  increase  data  processing  services  or  if 
the  implementation  of  a  good  back-up  plan 
would  require  recognition  by  the  senior 
management  of  the  high  jeopardy  with  which 
they  have  been  living  for  some  time  while 
assuming  risks  about  which  they  had  not  been 
told,  the  DP  management  may  opt  for  a  less 
workable,  basically  cosmetic  approach  to 
back-up  which  avoids  rousing  the  ire  of  that 
senior  management.  For  our  purposes  here,  we 
will  assume  that  there  is  a  sincere,  politi¬ 
cally  unfettered  desire  to  implement  the  most 
cost-effective  plan. 

The  split-site  approach  is  not  always  the 
best  approach,  but,  more  often  than  not,  it 
provides  the  most  cost-effective,  workable 
one  with  the  least  encumbrance  by  the  several 
negative  factors  listed  above.  We  will  now 
attempt  to  support  that  assertion. 

We  stated  above  that  it  is  very  rare  for  the 
critical  workload  to  exceed  50%  of  the  total 
workload  and,  more  commonly,  it  is  in  the 
order  of  20%  of  the  total.  Even  during  first 
shift  on  systems  with  heavy  interactive, 
real-time  loads,  well  more  than  50%  of  the 
work  is  usually  divertable  to  the  non-cr iti- 
cal  category.  When  such  is  not  the  case,  the 
most  burdensomo  applications  should  be 
examined  to  see  whether  some  of  the  work  done 
under  thorn  should  not  have  been  relegated  to 
batch  and  is,  instead,  being  done  unnecessar¬ 
ily  in  the  real  time  environment. 

If  less  than  half  of  the  total  workload  is 
critical,  then  it  is  clear  that,  at  least 
conceptually,  we  can  convert  a  single  facili¬ 
ty  into  two  without  increasing  the  total 
capability  and  have  either  of  the  two  parts 
be  large  enough  to  carry  the  critical  work¬ 
load.  Under  these  circumstances,  we  would  not 
need  to  involve  the  facilities  o£  other 
organizations  to  have  a  back-up  capability. 
It  is  clear  that  systems  do  not  cut  cleanly 
into  two  parts  of  precisely  the  relative 
sizes  we  might  want,  but  that  is  not  a  major 
problem. 

Split-Site  Costs. 

It  is  clear  that  one  cannot  divide  an  exist¬ 
ing  facility  into  two  parts  easily  or  without 
added  cost.  If  it  is  planned  carefully, 
however,  it  can  be  done  at  costs  sufficiently 
low  as  to  make  it  an  attractive  proposition 
for  most  organizations.  The  smaller  the 
critical  workload,  the  smaller  the  second 
facility  must  be  and,  normally,  the  lower  the 
cost  of  establishing  and  operating  that  site. 


The  economies  of  scale  dictate  it  to  be  less 
expensive  to  carry  a  workload  in  one  location 
rather  than  two  or  more.  This  is  not  a 
commentary  on  the  desirability  of  distributed 
processing  or  putting  DP  under  the  direct 
control  of  the  functional  areas  supported.  A 
given  DP  workload  is  normally  lesi;  costly  if 
it  is  done  all  at  one  place.  Because,  in  this 
case,  there  is  a  reason  for  splitting  the 
workload  between  locations,  we  want  to  do  it 
in  such  a  way  as  to  minimize  that  cost. 

it  is  reasonably  obvious  that  the  smaller  the 
second  site,  the  less  the  increase  in  the 
operating  cost  cf  the  two  sites  over  the  cost 
of  the  initial  single  site.  Thus,  the  second 
site  should  be  as  small  as  possible  and  still 
carry  the  critical  workload  and,  of  great 
importance,  be  a  fully  viable  facility  for 
carrying  whatever  normal  workload  is  appro¬ 
priate  for  placement  there.  We  have  found 
that  the  second  site  increases  the  operating 
costs  of  that  portion  of  the  work  brought  to 
the  second  site  by  about  20%.  Thus,  if  20% 
of  the  workload  in  moved  to  a  new  site  which 
ha9  a  capability  of  about  20%  of  the  initial 
facility,  the  increase  in  costs  incurred  by 
operating  at  the  two  sites  instead  of  one 
will  be  roughly  (0.20  X  0.20)  or  4%.  The  20% 
figure  .is  useful  only  for  initial  guidance 
and  should  be  confirmed  by  hard  estimates  of 
t.he  coots  in  the  specific  operating  environ¬ 
ments  under  consideration.  Many  factors  may 
influence  its  actual  value. 

If  the  20%  increase  can  be  confirmed  for  a 
specific  environment,  then  it  is  clear  that 
the  split-site  provides  a  highly  desirable 
back-up  option  if  there  are  no  other  signifi¬ 
cant  barriers  to  that  approach. 

Dividing  the  Workload  for  Split  Sites. 

There  is  probably  no  neeu  to  note  here  that, 
when  split  sites  are  planned,  as  much  as 
possible  of  the  critical  workload  should  be 
placed  in  the  facility  which  is  least  likely 
to  be  disrupted  for  any  reason.  This  is  not 
always  practicable,  but,  where  it  is,  it 
should  be  done. 

Many  organizations  already  have  a  split 
between  processors  handling  the  normal 
workload  and  those  supporting  development  and 
test,  although  these  processors  are  often  in 
the  same  physical  area  and  are,  therefore, 
jeopardized  by  the  same  infrastructure 
disruptions.  It  is  not  uncommon  to  find  that 
the  test  and  development  capability  is  large 
enough  to  carry  the  critical  workload  provid¬ 
ed  only  that  appropriate  access  to  essential 
communications  and  DASD  can  be  provided. 

Because  test  and  development  is  almost  always 
a  prime  candidate  for  suspension  when  normal 
processing  is  disrupted  and  back-up  of 
critical  applications  is  required,  running 
them  in  the  site  most  likely  to  be  used  for 
back-up  often  affords  an  ease  of  transition 
to  the  critical  work  when  that  is  needed. 

Putting  test  and  development  at  the  most 
secure  sits  might,  because  it  would  not  be 
needed  normally,  preclude  the  availability  of 


continuing  attachment  of  that  site  to  those 
communications  facilities  needed  to  support 
the  critical  applications.  Even  though  there 
might  be  an  intent  to  preserve  the  ability  to 
provide  the  communications  necessary  to  the 
back-up  capability  at  that  site,  it  is 
terribly  easy  for  that  ability  to  atrophy 
unnoticed  and  not  be  available  when  needed. 
Care  must  be  taken  to  avoid  that  problem. 

If  the  normal  workload  at  the  second  site 
requires  availability  to  the  communications 
facilities  which  support  the  critical  appli¬ 
cations,  then  no  hardware  or  extensive 
logical  shifts  need  be  made  to  run  those 
backed-up  applications  there.  It  is  quite 
fortunate  when  such  an  arrangement  is  feasi¬ 
ble. 

If  all  facilities  on  which  the  critical 
applications  might  be  run  when  back-up  is 
needed  are  on  the  same  SNA  network,  then  many 
of  the  communications  problems  are  fairly 
readily  resolved  provided  only  that  the 
disruption  did  not  incapacitate  a  signifi¬ 
cantly  large  segment  of  the  communications 
network. 

It  is  imperative  that  the  back-up  plan 
provide  adequate  means  for  back-up  of  essen¬ 
tial  communications  facilities.  They  are  too 
frequently  neglected  in  our  contingency 
plans.  Each  year  more  data  processing  time  is 
lost  to  catastrophically  damaged  cobles,  both 
copper  and  glass,  than  is  lost  to  physical 
damage  to  all  other  DP  components. 

Split  Site  Management. 

It  is  almost  uniformly  true  that  success  in 
bringing  any  good  contingency  plan  to  frui¬ 
tion  is  dependent  upon  the  support  of  thu 
director  of  data  processing,  by  whatever 
title.  In  many  companies  the  person  in  that 
position  has  fought  long  and  hard  to  preserve 
the  integrity  of  his  fiefdom  and  is,  quite 
understandably,  very  reluctant  to  see  it 
fractionated.  If  the  company  now  has  but  a 
single  cite  under  each  of  one  or  more  such 
persons,  it  must  be  anticipated  that  they 
might  well  oppose  the  establishment  of  a 
split-site  arrangement  unless  it  is  quite 
clear  that  they  will  retain  responsibility 
fox  both  sites. 

This  frequently  encountered  opposition  by  the 
DP  manager  to  a  second  site  unless  it  is  also 
under  his  management  is  a  good  thing  - 
sometimes  for  the  wrong  reason,  but  it  is 
usually  a  good  thing.  It  is  difficult  to 
imagine  a  situation  in  which  both  sites  of  a 
split-site  arrangement  should  not  be  under 
the  same  management.  It  is  important  that 
control  over  the  two  converge  at  a  level  not 
too  high  for  the  common  management  to  be 
fully  aware  of  any  activities  at  either  site 
which  might  threaten  the  ability  of  each  to 
pick  up  the  critical  applications. 

It  is  far  more  likely  that  two  sites  will 
remain  compatible  if  they  are  under  common 
management  than  if  they  are  not. 
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There  are,  unfortunately,  many  examples  of 
back-up  arrangements  within  the  same  organi¬ 
zations,  many  of  which  were  fully  and  success¬ 
fully  tested  in  the  past,  but  where  the 
systems,  which  were  supposed  to  be  and 
thought  by  the  senior  management  to  be 
mutually  supportive,  grew  in  ways  which 
negated  the  capability  to  back  up  each  other. 

In  a  number  of  the  more  notable  examples, 
these  differences  were  intentionally  intro¬ 
duced  by  the  DP  directors  to  achieve  for 
their  particular  facility  some  superior 
capability  or  service  level  not  possessed  by 
the  other. 

Site  Locations. 

It  may  not  be  possible  to  satisfy  all  of  the 
desiderata  appropriate  to  the  location  of 
split  sites.  The  relative  importance  of  each, 
and,  thus,  the  need  to  satisfy  it,  is  best 
judged  in  the  light  of  the  particular  operat¬ 
ing  environment.  The  more  important  ones  are 
these: 

1.  Proximity.-  The  two  sites  should  be 
sufficiently  close  that  it  is 
logistically  feasible  for  each  to 
store  the  back-up  data  for  the 
other.  In  general,  this  is  to  say 
that  the  two  should  be  within  a  few 
hours  drive  by  motor  vehicle. 

2.  Physical  Dispersion.-  They  should 
be  far  enough  apart  that  they  are 
not  subject  to  the  same  causes  of 
disruption  provided  that  the 
probability  of  encountering  those 
problems  is  weighed  realistically. 

3.  Independence,-  So  far  as  possible, 
the  facilities  should  be  located  so 
as  to  be  free  of  dependence  upon 
elements  in  the  infrastructure 
which  are  known  to  be  shaky.  These 
include  factors  ranging  from  power, 
communications,  water,  sewer, 
transportation,  susceptibility  to 
tornadoes  and  hurricanes,  flood 
plain  problems,  riot-prone  neigh¬ 
borhoods,  proximity  to  major 
highways  and  railroads  which  offer 
the  potential  for  chemical  spills 
which  will  require  evacuation  of 
the  facilities,  and  other  such 
factors . 

THE  FUTURE 

Distributed  processing,  the  growth  of  depart¬ 
mental  computers,  and  the  rapid  proliferation 
of  microcomputers  will  all  contribute  in 
large  measure  to  the  problems  of  contingency 
planning  just  as  they  contribute  greatly  to 
both  the  efficacy  and  the  complexity  of  our 
information  systems.  We  can  find  no  reason 
for  an  assumption  that  they  will  serve  to 
decrease  the  si -e  of  single-site  data  aggre¬ 
gations  to  whiun  access  will  be  required  for 
the  efficient  conduct  of  our  businesses. 

The  cost  of  data  storage  continues  to  de¬ 
crease  as  do  access  times  and  both  of  which 


serve  to  accelerate  growth  in  the  volume  of 
data  to  which  we  want  access.  It  is  inevita¬ 
ble  that  continued  growth  in  data  aggregation 
size  will  greatly  change  the  nature  of 
contingency  plans  which  are  practicable  in 
support  of  very  large,  high  data- volume 
business  systems. 

We  expect  to  see  the  advent  of  super-safe, 
underground  DASD  facilities  connectable  to 
geographically-remote  large  and  small  proces¬ 
sors  through  very  high-speed  communications 
facilities  leaving  us  with  the  need  to  back 
up  only  the  processors  and  provide  alternate 
means  of  communications. 

At  this  time,  we  find  very  little  reflection 
in  workable  contingency  plans  of  recognition 
of  our  growing  dependence  on  microcomputers 
and  minis.  It  may  well  be  that  we  will  not 
see  significant  change  in  that  until  some 
major  organization  has  a  very  serious  problem 
as  a  result  of  being  unprepared,  but  we  have 
almost  no  confidence  in  that  as  a  motivator 
of  others.  The  problems  of  others  has  not 
been  a  primary  source  of  motivation  for  such 
contingency  planning  as  we  have  seen  about 
mainframe  facilities.  Host  such  losses  are 
not  broadly  publicized. 

The  slowly  increasing  competence  of  internal 
auditors  in  the  technical  aspects  of  data 
processing  should  serve,  in  the  foreseeable 
future,  to  alert  corporate  managements  to  the 
need  for  better  contingency  planning.  We 
expect  that,  rather  than  the  grief  of  others, 
to  accelerate  the  emphasis  on  contingency 
plans  which  address  the  whole  of  the  data 
processing  dependency  as  well  as  recognition 
that  there  are  many  other  parts  of  our 
businesses  other  than  data  processing  which, 
if  disrupted,  have  the  potential  for  causing 
great  harm. 

SUMMARY 

A  wide  variety  of  approaches  to  contingency 
planning  is  available  to  the  persons  charged 
with  designing  such  plans.  The  task  requires 
innovation,  much  common  sense,  rejection  of 
all  cookbook  approaches,  and,  above  all, 
prior  identification  and  quantification  of 
the  losses  potentially  averted  by  the  proper 
plans.  No  contingency  plans  are  so  inherently 
desirable  that  they  should  be  implemented 
without  solid  economic  justification. 

Contingency  planning  is  as  much  dependent 
upon  understanding  human  nature  as  it  is  on 
understanding  the  technical  aspects  of  our 
systems.  Unless  people  at  each  organizational 
level  from  which  we  need  support,  or,  at 
least,  lack  of  opposition,  can  be  motivated 
to  support  back  up  and  recovery,  it  is  very 
difficult  to  put  in  place.  Strong  senior 
management  support  born  of  awareness  of  the 
need  for  it  contributes  more  than  any  other 
factor  to  the  success  of  contingency  planning 
-  but  even  that  is  not  a  guarantor. 

One  thing  of  which  we  are  certain,  because  it 
has  been  demonstrated  repeatedly,  Is  that 
good,  workable  contingency  plans  are 
economically  feasible. 
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